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(54) Tillo: VIRTUAL PROPER'I'Y SYSTEM 
(57) Al».stract 

A system of property ownership and transfer that can 
lie used in connection with a computer network. The system 
pennits limited edition, digital olijecLs lo be created and 
exchanged for value. 
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VIRTUAL PROPER l Y SYSTEM 

i' ield of the Invention 

The present invention relates to computer networks and, more particularly, to a system 
of property ownership and transfer implemented in connection with a computer network. 

5 Background of the Invention 

in recent years, the use of computer networks for communication and data processing 
has become increasingly widespread. The increased availability and use of computer networks 
has created possibilities for new kinds of business and interactions. For example, many people 
now conduct business transactions, such as banking or retail transactions, over the Internet or 
10 private computer networks Others use the Internet to participate in interactive, multi-party 
games that could not have existed before the advent of computer networks. 

Computer network users generally attempt to exploit the unique features inherent in 
communications over computer networks Owners of valuable data or ''content/' such as 
software developers or entertainment companies, take advantage of the relative ease and speed 

15 of data replication and transmission over computer networks to inexpensively distribute their 
data to vast audiences. Retailers and advertisers utilize the relative cost-ctTectiveness and 
ready searchability (as compared to conventional publishing media) of data published on the 
World Wide Web to make information available to vast bodies of potential customers 
Multinational businesses use the medium to allow immediate and inexpensive communication 

20 among employees in various parts of the world. 

In each of the above situations, technical challenges must be overcome. Content 
providers generally seek mechanisms to ensure receipt of payment for any copies of their 
content which are distributed, and to ensure the integrity of the data transmission Retailers 
desire mechanisms for conducting secure commercial transactions over the Internet. Those 
25 communicating at a distance often require security and confidentiality of data transniission, 
and means of authenticating the origin of data received. 
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I'hesc cluillciiucs ucncrally arc overcome hy applyinu common crypioizraphic tech- 
niques to eliminate data security or privacy concerns, while still allowing users to take 
advaiUage of the unique features oi the new medium. For example, common cryptographic 
lechnit|ues are available to allow authentication of the sender of a digital message, and to 
ensure that such a message is opened only by the intended recipient. Data metering systems 
provide a mechanism for content providers to charge for use of their data A software 
provider may also use a conventional "digital signature" to sign code that is being distributed 
!o users, thereby allowing users to rely on the quality of the code received. 

In some cases, however, it is desirable to eliminate certain perceived ''advantages" or 
inherent features of the new medium, and extend familiar limitations of the physical world into 
the electronic realm In the case of digital cash, ibr example, it is necessary to prohibit 
"counterfeiting " fhis is accomplished by introducing digital ec|uivalents of the security 
features that protect against counterfeit paper currency. 

^fraditional features and limitations of ownership and property rights are also some- 
times desirable within the computer network environment In an interactive game environ- 
ment, for example, users might purchase or otherwise obtain "property" which can be 
voluntarily or involuntarily transferred to other users This game "property" may represent a 
physical item that, in the context of the game, should not be counterfeited or duplicated 
readily Thus, tor example, the seller of a game object siuMild not be able to retain a usable 
copy of the sold item 

Previously, "I here was no adequate, reliable and sufficiently secure system for establish- 
ing traditional features of ownership and property rights in the digital realm Accordingly, 
there is a need for an improved system of properly ownership and transfer that can be 
implemented in connection with a computer network. 

Siinuiiiiry of the Invention 

The present invention involves a system of properly ownership and transfer that can be 
implemented in connection with a computer network. 
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C'crtain cnibodiinciils oi'ihc present invcntK)ii oiler iiiany advantages, ineluding 
without limitation the follovviiig; 

(a) enabhng a traditional property riglits system in a computer network environment; 

(b) enabhng a system of properly ownership atid transfer in connection with a 
5 computer network; 

(c) enabhng new ty|)es of interactive, muhiparty comptiler games; 

(d) aHowing persistent digital property used in connection with a computer network to 
be transferred oiTline or online; and, 

(e) establishing mechanisms for tracking ownership of virtual property. 

10 fhese and many other advantages cU' certain embodiments of the present invention will 

become apparent to those skilled in the art from the present patent application 

Brief Description of the Drawings 

FIG. I is an overview of an embodiment of a virtual property system according to the 
present invention, 

i 5 FIG. 2 illustrates the basic relationships among elements of an embodiment of a virtual 

property system according to the present invention 

FIG. 3 illustrates a consumer login scenario used in connection with an embodiment of 
a virtual property system according to the present invention. 

FIG. 4 illustrates a web purchase scenario used in connection with an embodiment of a 
20 virtual property system according to the present invention 

FIG. 5 illustrates an accoimt checking procedure used in connection with an embodi- 
ment of a virtual property system according to the present invention. 

FIG. 6 illustrates a procedure for posting a newly created object for sale in connection 
with an embodiment of a virtual property system according to the present invention. 
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FlCi. 7 ilUistrates a pioccdurc lor posiiiiu a prcvK)usly acciLitred ohjecl toy resale in 
connection with an cnilx)dinient of a virtual properly system according to the present 
invention. 

f'IG. 8 illustrates tiie structure oFa limited edition digital object used in connection 
5 with an embodiment of a virtual property system acc(M'diiig to tlic present invention. 

FIG. 0 illustrates aspects of a procedure according to FIG. 6. 

Detailed Dcscriplioii of rreferrcd Einbodiiiicnt^s) 

Overview 

A preferred embodiment of a property ownership and transfer system according to the 
10 present mvention is illustrated in FIG. I and F IG 2 and rcfcned to herein as a "Transactor" 
system The illustrated Transactor system invt)lves a database 10, a Fransactor server 20, 
end-users M), a Transactor broker 40. and an application serA ice provider {c.yr, a game server) 
50. End users M) comprise end-user computers (or "terminals") 3 !, 32, and 33, and end-user 
individuals 35, 36, 37, and 38. 

1 5 The illustrated 1'ransactor system may include any number of end-users and/or end- 

user terminals, an additional terminal and an additional user labeled " " are included in FIG. 
[ to illustrate this fact. Database 10 and Transactor server 20 may each comprise a plurality 
ot databases and set-vers, respectively, i.-mbodiments of the system optionally may include any 
number of Transactor brokers and application service providers with any number of associated 

20 end users 

The application service provider may be a general Internet service provider (c.^r, AOL, 
CompuServe, Pacific Bell), a game specific service provider (t'.^i;., Mpath, Heat, TEZN), an 
open network market-specific service, a closed or private network service, or any other 
service provided over a computer network. For illustrative purposes only, the below discus- 
25 sion emphasizes the example of a Transactor system in which the application service provider 
comprises a game server, and the end-users comprise game clients, 

4 
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l-nd users 30 ifUeract with one nnolher and witli game server 50 over a computer 
network ((^^^, the Internet) 60 in a virtual world (t'.^t;. , an interactive environment governed by 
a prescribed set oT rules) provided by game server 50 and supported by Transactor server 20 
In this virtual world, digital property can be owned by. used, and transferred among end users. 
End users can also transfer digital property while oQline (i.c.^ not in communication with the 
game or Transactor servers). Transactor server 20 communicates with Transactor broker 40 
over the Internet 60 or, optionally, by a direct communications link. 

As illustrated in FIG. 2, other optional participants in the illustrated Transactor system 
include Transactor-enabled vendors web sites) 70, a consumer's credit account holder 
80, and a consmner's bank account 00 Transactor-enabled vendors preferably are accessible 
via the internet 60, as are consumer's credit account bolder HO and consumer's bank account 
00. 

The illustrated Transactor entities can be categorized broadly as clic/tfs and/or servers 
Some entities may act as both a client and a server at the same time, but always as one or the 
other with regard to other specific entities For example, a game server acts as a client to a 
Transactor server, but as a server to its game clients 

The main categories of computing entities in the overall Transactor hierarchy are: 

( 1 ) Transactor scfA/ers; 

(2) Transactor clients. 
( .>) game servers; and 

(4) game clients (who are implicitly also Transactor clients) 

It should be noted that these computing entities do not necessarily map directly onto 
individuals, companies, or organizations An individual. Tor example, may have more than one 
Transactor account. Similarly, a game company may set up game servers with more than one 
Transactor account. 

I . Transactor Servers 
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As described Ihrtlicr below. Transactor servers [Movide transaction and ovvnershi[) 
authentication to their clients, who may be other Transactor servers, game servers, game users 
(which are game clients acting ihrougii a game server) and Transactor users (which are not 
acting through any game server) 'Transactor servers operate on Transactor user accomits and 
5 eticapsulated Transactor objects; they need not know the details of any particular game world 
that may exist. 

The Transactor servers essentially deline a marketplace in which safe transactions may 
occur, and existence and ownersiiip may be asserted and verified under rules [i.e., "t ransactor 
Laws of Nature") defined lor the Transactor system as a whole The primary purpose of the 

10 Transactor system is to ()rovide a sate mai kel place tor objects and owners oaisulc the scope of 
miy \^amc in which those objects and owners might participate If a potential game does not 
recjuire its game objects to exist outside the scope of its game universe, then using fransactor 
to determine autiienticity and ownership is not necessary It may, however, be more conve- 
nient or easier to use Transactor services than lo create a special-purpose property ownership 

1 5 and transTer system for tliat game 

A given Transactor server is responsible Tor the objects and users defined in its own 
database. A fransactor server trusts otlier Transactor servers for validation of all other 
objects and users It can, however, detect certain kinds of cheating that might occur in its 
conversations with those other fransactor servers. 

20 In some embodiments, a group of Transactor servers have secure access to a shared 

distributed database. In such embotliments, the group of servers appears, for most purposes, 
as a single large Transactor server acting on a single database. 

2 Transactor Uscr.v 

Transactor users are users that are in direct communication with a Transactor server, 
25 rather than in communication through an intermediary game server 'I hus, they are limited to 
the core Transactor activities of creating objects, making transactions, and authenticating 
ownership and existence All other activities are performed through a game server. 

3. Game Servcr.v 

6 

SUBSTITUTE SHEET (RULE 26) 

BNSOOCID; <WO .9847091 Al J - 



wo 98/47091 



rCT/lJS98/07l76 



I o a I ransactor server, a uanic server is a I'ransactur user that pertbrins transactions 
and liinited tyj^es oi authcnticatiDiis (c.i^.. verify yanie membership). Among themselves, 
however, game servers define, in a conventional mantier. a game ^ universe" or "virtual world" 
for their clieiits, and operate on a set of game objects using game rules that the game designer 
defines for that game. A game universe includes all servers that run the game, the game 
software's behavior, and the rules that define possible behavior for thai game. 

4 Game userv 

Game users are the participants in a game Lini verse that exists on one or more game 
servers, Preferably, most IVansactor operations on the game's owned objects arc brokered by 
the game server, acting on behalf of the game user In such embodiments, the only time a 
game ttser appears as a Transactor user is when object ownership must be authenticated or 
changed I:.ven then, however, this activity may be brokered by the game server acting within 
the scope of the game universe's possible actions 

The components of the illustrated Transactor system, along with their implementation 
and use, are described in more detail herein. Prior to such description, however, basic 
operations and transactions in an embodiment of a Transactor system are described. 

Scenario Fxarnplcs 

Tiiis section describes various uses of a Transactor system in the form of exemplary 
"scenarios," which are illustrated in ITGs 3, 4, 5, 0, and 7. A scenario is an exemplary use of 
Transactor technology to accomplish some purpose for a user. A user may be a consumer, a 
vendor, or any other user of the Transactor technology, including an intermediate server 
program that subscribes to Internet-based Transactor services; for convenience, the user is 
referred to consistently in these scenarios as a consumer. 

The illustrated scenarios are representative examples only. Other scenarios and their 
implementation will be apparent to those of ordinary skill in the art based on the present 
disclosure. The scenarios refer to the elements of the Transactor system illustrated in FIGs. I 
and 2, along with ceriain details and components described further herein. 

The Login Scenario (FIG. 3) 

7 
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riCi 3 describes a j^roccss in wiiich a user Iol^s r>n, and opiionally registers as a 
Transactor user, in an exeniplarv cinbodinicnt of a Transactor system. As illustrated in FTG, 3, 
the (bliowing steps take place. 

In step I (illustrated at 102), the consumer user 35) loys onto the liiternet 60 

In step 2 (at 104), the consumer logs onto a I ransaclor enabled service provider (or 
onto a Transactor sei^vcr). 

At this point, there are several possibilities. The consumer may decide to register as a 
Transactor user (step 3, at I Ob) Altcrnalively, the consumer may decide not to register as a 
ITansactor user and, consequently, leave the site (step 14, al 128) Alternatively, the 
consumer may already be a registered Transactor user (step S, at 1 I 8) and have no need to 
register as a Transactor user. 

Assuming the consumer decides to register as a Transactor user, the consumer fills out 
a registration form (step 4, at 108), identifying his or her charge account and bank account 
information When the consumer has entered the rec|uested inibrniation, the information is 
submitted to a Transactor server (step 5, at I 10), The Transactor server creates a new 
account and issues private data (ci^., user key, password) to the consumer (step 5, at I !2). 
The consumer receives and stores the keys and other data, and obtains the I'ransactor client 
software ic^r^ bv download or mail) (step 7, at 1 14) 

After the consumer has become a registered Transactor user (after completing step 7 
or step 8), the consumer logs into the client-side Transactor object manager (which is 
described further herein and abbreviated " TOM") as a valid user (step 0, at 1 16), 

After logging in as a valid user, the consumer has a variety of options. The consumer 
may decide (Step 10) to make a purchase (illustrated at 120 and in FIG. 4). The consumer 
may decide (step 1 I) to check his Transactor account (illustrated at 122 and in FIG. 5). The 
consumer may decide (step 12) to post an object that he has created ibr sale (illustrated at 124 

8 
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nnd ill FlCi O) I'he consuincr may decide (step \}) to p{>si a pieviuusly acquired i)l)ject fur 
resale (illustraied at 126 and in FIG. 7). 

I he C'oiisiinier Weli-Purchase Scenario (TIG. 4) 

riG 4 ciescribes the process in vvhicli a user makes a simple purchase iVom a web sales 
site and uses ihc new object on the network in an exemplary embodiment of a I'ransactor 
system. As illustrated in FIG, 4, the following steps take place: 

In step I (at 202), a consumer (c.i^., user 33) decides tt) make a purchase. The 
consumer's TOM sends (step 2, at 204) signals indicating an intent to purchase, along with the 
appropriate user ID and product information, to the vendor's web site. The vendor's 
Transactor broker module creates (step 3, at 206) a transaction record that incorporates 
necessary vendor IDs, product information and vendor signatmes with consumer's informa- 
tion. 

The vendor then sends (step 4, at 208) a transaction record, as described further 
herein, to the Consumer's TOM for signature. The consumer's TOM confirms (step 5. at 210) 
tiie vendor's signature and transaction record contents, and signs and forwards (step o, at 212) 
the transaction record to the Transactor server. The consumer's TOM also notifies (step 7, at 
214) the vendor's server that the transaction has been signed and a record has been forwarded 
to the Transactor server. 

The Transactor server then validates (step 8, at 216) the Transaction record and 
contents, issuing an OK (i.e., transaction is valid) or a rejection (transaction is invalid) If the 
validation is not OK, tlie operation is not performed and the user is so [lotified (step Oa, at 
218). If the validation is OK, the Transactor changes (step 9b, at 220) the object's ownership 
in the relevant database and determines all splits and fees for all accounts involved (t'.^t,^, buyer 
reseller/ maker, service provider); transactions for each account arc then logged and new 
account balances are computed. 

The Transactor server then sends (step 10, at 222) a purchase (.^K to the vendor's 
server, and the vendor's server receives (step I I, at 224) the OK and repackages the existing 
unit with the consumer's ID. 

9 
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rtie vendors scivlm ilicii sends (slop 12, at 22()) the object io tlic consumer or sends 
notification of where to di)vvnhKKl the t^hjcct via FTP Tlie sale is louged as complete. 

Finally, the consumer's TOM server receives (step 13, at 22S) notice of the sale and 
downloads the object according to the instructions received in step 12. When the object is 
5 subsequently used online, a Transactor server will verify the ownership of the object. 

Hie Corisiinicr Account-Check Sceiiiirio (FIG. 5) 

FIG. 5 describes the jirocess m which a consumer checks his fransactor account. As 
illustrated in FIG. 5. the following steps take place; 

hi step 1 (at 302), a consumer {ci^., user 33) decides to check his Transactor account 

10 Tlie consumer's lOM sends (step 2, at 304) inlent-to-purchase account information 

(with appropriate user IDs) to the Transactor Server, either directly or via a transactor 
enabled web site or broker server I he fOM may operate independently or through other 
Transactor enabled client software The Transactor server then sends (step 3, at 306) a 
validation challenge to the consumer's I'OM, and the consumer's TOM responds (step 4, at 

1 5 308) to the validation challenge. I lie Transactor server receives the response (step 5, at 310). 

If the validation is not OK, the operation is not performed and the user is notified of 
the failure (step 6a, at 3 1 2) 

if the validation is OK, the I ransactor server allows (step 6b, at 314) the client 
software (c.^- Java applets) to download the consumer's account information (not persistent). 
20 The consumer's I'OM downloads (step 7, at 316), deciypts and displays account information 
using applets (or other client software) embedded in the web peige (part of broker module, 
described iiercin). 

The consumer then reviews (step 8, at 3 18) account information (along with other 
communications from the Transactor server, if any have been received) and logs olTor 
25 proceeds to other Transactor activity. 

The Sale of Created Object Scenario (FlC. 6) 
10 
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1* ICf. 0 describes the process in wliicli a registered I ransactor user posts an ohject that 
he created for sale. As illustrated in TIG. 6, the following steps lake place. 

In step I (at 402), a registered Transactor user {c.i:., user 35) decides to post an object 
that he has created for sale The user the (step 2, at 404) logs into the TOM to "package" his 
object, the TOM enters (step 3, at 406) the user ID (c.t;., Al Al Al) into the object package 
lleids, and the user inputs data regarding, for example, piice, reventie model, and number 
available. 

f he user logs on (step 4, at 408) to a Transactor Server directly or a Transactor- 
enabled service provider, and is validated by a Transactor Sei-ver The user then uploads (step 
at 410) the packaged object and fields with instrticiions for the Transactor Server to create 
a new product. 

I he I iansactor Server then verifies (step (\ at 412) that it received the data correctly, 
and proceeds to create a product, giving it a uniciue prodtict ID (Bl IB I ). The f ransactor 
Server then sends (step 7, at 414) the unique product ID, and other prodtict-related informa- 
tion, back to the user 

When copies of the product are sold, the Transactor Server will verily (step 8. at 416) 
buyer's (37) Transactor User status and the existence of available unsold units for the buyer- 
designated prodtict ID. 

If the validation of user ID or product ID is not OK, the operation is not performed 
and the tiser is so notified (step 9, at 418). 

If the user ID and product ID are OK (step *^b, at 420) to produce a new unit of the 
product, the Transactor Sei ver creates a new unique tinit ID and assigns ownership of that 
unit to the buyer in its internal ownership databases The 1'ransactor Server then packages 
(step 10, at 422) the unit ID with ownership information and the digital [)roduct itself, 
encrypts portions of the resulting data, and sends the result to the user or informs the user 
where the packaged object may be downloaded The Transactor Server also updates (step I I, 
at 424) all relevant accounts, computes and distributes splits. 

The Sale of Previously Acquired Ohject Scenario {FIG, 7). 

I I 
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I IG 7 describes the process in vvhicli a reuisteietl IVansactor user posts a previously 
acquired object ibr sale. As illustrated iii FIG 7, ilie followiiii^ steps lake place: 

In step 1 (at 502), the Consumer decides to post a previously acc|uired object for 
resale. Using the TOM, the Consumer then indicates (step 2, at 504) the asking price for the 
5 object and sends posting (and appropriate IDs including TOM signature) to the Transactor 
Server. 

The Transactor Server then sends (step at ."^06) a validation challenge to the 
Consumer's TOM The Consumer's TOM responds (step 4, at 508) to the validation 
challenge The Transactor Server receives (step 5, at 510) the response. 

10 [f the validation is not OK, the operation is not performed and the user is so notified 

(step Oa, at 512). 

If the validation is OK, the Transactor Server includes (step ()b, at 514) the object 
posting in a log of objects currently for sale "classifieds." 4"he object, or a pointer to the 
object, is stored at a Broker Server for resale. 

15 Another valid Transactor user, for example Consumer 36, logs on (step 7, at 5 16) to a 

IVansactor enabled web site and activates her TOM to search for an object to purchase. 
Consumer 36 searches (step S, at 518) the Transactor ''classifieds" by object name, universe, 
price, or any other conventional search criteria tt> find the desired object 

Consumer 36 then locates (step at 520) tiie object posted by Consumer 35 and 
20 decides to make a purchase. The TOM for Consumer 36 then sends (step 10, at 522) its intent 
to purchase (and appropriate IDs) to the Broker Server via the Transactor-enabled web site. 
The purchase process continues (step ! 1, at 524) as in FIG 4, with the Broker Server acting 
as vendor. 

Limited Edition Digital Ohjcct 

25 The Transactor system allows for the ownership and sale of limited edition digital 

objects. An exemplary limited edition digital object (a ''LEDO") 600 is illustrated in FIG. 8 
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As sIkhvm ill KICi. K. l,I^D() (>()() comprises a [layload 60h, a unit ID 602, and an owner 
ID ()04. [vdch ofthcse elements are illustrated in corresponding dashed boxes. Hxaniples of 
LI'DOs lor use in ij^anie environment in connection with an emhodimenl ofa Transactor 
system comprise tools, characters, keys, spells, levels, abilities, behaviours. A variety of 
additional types ofLEDOs For use with embodiments ofa Transactor system will be apparent 
to those skilled in the art from the present disclosure In this example, each IT^DO has a 
unic|ue, immutable unit ID, an owner ID indicating the current owner ofthe object and a 
payload comprising binary data which defmes the object characteristics. 

Unit ID 602 is assigned to the unit during object creation and incorporated in the 
liiDO during the initial object ptirchase The owner ID 604 is assigned to the user during 
User Registration and incorporated in the L.TZDO during object purchase Payload 606 
comprises data which defines the object (t'.tf., textures, data pointers, Al, object attributes) In 
preferred embodiments, the objects are persistent such that they are accessible both when the 
user is in communication with a server {c.i^., a game server) and when the user is not in 
communication with the server 

The number ofLliiDOs ofa particular type can be closed or limited {ci^., the product 
run is capped at a predeterniined number) or open-ended. The unit ID for each LCDO is 
assigned at its creation and is unique The unit ID is immutable in the sense that a change in 
the unit ID for a particular I.T':DO can be detected and, in preferred embodiments, the I. EDO 
loses functionality (cA^r, it cannot be used in the relevant game world) if it has been altered. 

Additional Aspects ofthe Sale of Created Object Scenario (FIG. 9) 

FIG. 0 describes the process in which a registered Transactor user posts an object that 
he has created for sale in accordance with the previous description in FIG. 6 The following 
description ofthe steps in this process uses the FIG. 6 reference numerals and step numbers, 
along with the FIG 9 reference numerals; 

In step I (at 402), a registered 'I'ransactor user {cy;., user 35) decides to post an object 
that he has created for sale. The user the (step 2, at 404) logs into the TOM to "package" his 
object, the TOM enters (step 3, at 406) the user ID (c.^r, Al Al Al ) into the object package 
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fields, atui the user inputs data ici^ardiny, tbi example, price, revenue model, and number 
available. 

riic user logs on (step 4, at 408) to a Transactor Server directly or a 'I'ransaclor- 
enablcd service provider, and is validated by a I'ransactor Server. 

5 Steps 1 through 4 above are further illustrated in FIG 9 by User 35 (identified by code 

Al Al Al ), digital object 700 (ci;.^ a file contaniinu binary data), transactor package 710 
which wraps the object as described herein, and data fields 720 Data fields 720 include a 
product ID field 722 for the identification code associated with the object (in this case, 
B I B IB 1 ), a seller ID field 724 for entering an identification code associated with the seller of 

10 the object (in this case, Al Al A 1 ), an owner ID field 726 for entering an identification code 
associated with the owner of the object (in this case. Al Al Al ), a price field 728 for entering 
the rec|uested price for the object (in this case, $^ 00), a maker \\) field 7.10 for indicating the 
identity of the maker of the object (in this case, A I Al Al, the owner), a revenue model field 
732 to indicate financial terms associated with the sale of the object ( in this case, a straight 

15 sale), a total available field 734 indicating the total number of objects of this type that are 
available for sale, and an ITP field 736 indicating the delivery details for the object In this 
case, for example, liie field shows a URI.> for a web site from which the buyer can download 
his purchased object, fhe object is enci^pted so that it can only be "unpacked" (opened) by 
the buyer. 

20 The user then uploads (step 5, at 4 10) the packaged object and fields with instructions 

for the t ransactor Server (illustrated at 740) to create a new product. 

The l iansactor Server (740) then verifies (step 6, at 412) that it received the data 
correctly, and proceeds to create a product (illustrated at 750), giving it a unitjue product ID 
(BiBl Bl ) shown in data field 762. fhe Transactor Server then sends (step 7, at 414) the 
25 uni(|ue product ID, and other product-related information, back to the user. 

When copies of the product arc sold, the Transactor Server will verily (step 8, at 416) 
buyer's (in this case, user 37) T ransactor User status and the existence of available unsold 
units tor the buyer-designated product ID 

If the validation of user ID or product ID is not OK, the operation is not performed 
30 and the user is so notified (step 0, at 4 18), 
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It the Liscr ID and product ID arc OK (step 91). M 420) to produce a new Linit oftlie 
product, the Transactor Server creates a new unique unit ID (illustrated at data field 76S and, 
in this case, D I D I D 1 ) and assigns ownership of that unit from the seller ( A i A I A I , illustrated 
in data field 764) to ihe buyer (ClClCI illustrated in data field 76()) in its internal ownersliip 
databases and in the new object (relevant data is illustrated in data fields 760). The Transactor 
Server then packages (step 10, at 422, also illustrated at 770) the unit ID with ownership 
information and the digital product itself, encrypts portions of the resulting data, and sends the 
result to the user or informs the user where the packaged object (illustrated at 770) may be 
downloaded. The Transactor Server also updates (step I I, at 424) all relevant accounts, 
computes and distributes splits. 

I riist Rci^ilioiiships 

The illustrated Transactor system is predicated upon various trust relationships among 
the Transactor entities illustrated in FIGs 1 and 2 These trust relationsiiips are as follows: 

1 7'mf m icior Sen 'crs 

A Transactor Server trusts other Transactor Servers to correctly authenticate objects 
and accounts which are outside its own knowledge. This trust is mutual. 

A Transactor Server does not trust a Transactor User. Accordingly, a Transactor 
Server does not trust a game Server. All transactions and authentication must be valid 
according to the i ransactor protocol rules, or a transaction request will be rejected Both 
participants in any transaction are independently authenticated by the Transactor Server. 

2. I'ransactar I Iscrs 

A Transactor User trusts all Transactor Servers to give correct information about 
transactions, objects, and accounts. 

A Transactor User does not trust another Ti ansactor User, except to the extent 
authenticated by a Transactor Server. 

3. Game Servers 
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(iainc Servers, like other I iansaclor Users, trust their TransaelDr Servers to perlbrni 
valid ovvuershif) iransibrs, and lo correctly authenticate user-accounts and ohject tnvnership. 
Cianie Servers also trust ihe Traiisacior Server to authenticate yaine objects themselves [i.e., 
delect data tamperiiiL;), hut only insofar as the oriuinallv reuislered game object was itself 
5 correct in the game universe. That is, if the originally tegistered game object was Hawed or 
illegal for the game universe, it will be ''ct^irect'" as far as the Transactor Server is concerned, 
but will be "iiiccMTcct" when the game server tries to use it 

(ianie servers need not trust their game users In some embodiments, lunvever, game 
servers may trust game users without a t ransactor server authentication. 

10 Game servers trust other game serveis that help create the game universe 

4 ( lumc Users 

Game users trust game servers to "piay a fair game" (/.c, follow the rules of tlie ganie 
universe). Game servers that do not [)laY a fair game are unlikely to be successful in the game 
market, but there is no final Transactor arbiter of what constitutes a "fair game " 

I 3 A game user need not tnist another game user, except insolar as confirmed by the 

game server for the given game univeise 

rraiisactor nrokcrinjj; 

This section includes a description of how, in an embodiment of a fransactor system 
according to the present invention, objects may be bought, sold, and traded using a mutually 

20 trusted third party (a broker) in order to etVect transactions in other than real-time F'or 

illustrative purposes, this is described in terms of a "game," the rules of which define a model 
of conventional real- world brokering and agency. A typical problem involving a game, game- 
players, and ownership transfer is first presented. This example is followed by a brief analysis 
of a "simple solution," which can be used in simple embodiments of a Transactor system. 

25 Finally, there is a discussion of brokers, their actions, rules, and how this solves the basic 

ownership-transfer problem when implemented in more complex embodiments of a Tran.sactor 
system. 

16 
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1 A/i l^xc/ftrlcirv ( ntmc Sccniuio (tml I/nnlc^ficn/dnifN I'roh/c/n 

This example involves a simple nuitu-player game, runniiii^ on a server machine I he 
players own some Transactor objects, which reside on their own machines. A few players 
decide to play a yamc using some (btit not all) of their owned objects, using the game seiA/er 
to run the ' game world." 

The rules of this game allow game objects (encapsulated as Transactor objects and 
initially existing on the player's machines) to be involuntarily "plundered" by the brute force or 
trickery of any player, as well as voluntarily traded away, or simply lost or dropped. In this 
game, possession eciuals ownership Lost or dropped objects not picked up by another player 
are "owned" by the game (or game service provider). A Transactor server is contacted and a 
transaction (a Transactor ownership tratisfer) made each time a game-object changes owner- 
ship, (^'.,t,^, it is plundered, traded away, lost, dropped). 

To begin playing the game, users upload (or otherwise identify) their objects to the 
game sei*ver, which authenticates ownership and validity with the 'Transactor server. During 
play, an object changes hands, so an ownership transfer occurs, and the Transactor server is 
again contacted, with all the overhead such an ownership change entails. Liach transaction 
also requires the owner's client machine to participate, since that is where the itser's digital 
keys, required for ownership transfer, reside. 

I he basic problem is how a game server or anyone else in the above scenario can truly 
enforce transferring ownership involuntarily; that is, without the active assent of the object's 
original owner. Under ordinary circumstances, the owner cannot be compelled to use or 
disclose his private key and, without it, ownership cannot be taken away. Even if the game- 
client software running on the player's niachine automatically responded to a game server 
request to transfer ownership, the user could have hacked the software to not permit owner- 
ship transfers. Thus, in conventional circumstances, the game server would have no way to 
enforce ownersliip transfer to the object's new owner. 

One conceivable solution might be to have the game sei'ver certify to the Transactor 
server that a new player is tiie actual owner, and to somehow confirm that it really is the game 
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server rcqucstinu this. I liis approach appears simple, hut would require urealer underlyiiv-i 
complexity in the overall TransacK^ system. There would then be two kinds ol" transactions: a 
volunlai y kmd where both participants willingly stale that a transaction should occur (normal 
sale or trade), and one where a third participant (tlie uame server) says that a transaction 
5 shotild occur, even if the owner doesn't agree This arrangement would also require that 

I'ransactor servers trust all game servers, thus opening up potential holes in tlie overall system 
security model and greatly expanding the reciuired trust relationships in the twerall system It 
would also require that Transactor servers distinguish a game-server account from other kinds 
of accounts, and treat them dilTerentiy 

In a large game with a persistent universe, this apparent solution vvotild force the 
Transactor servers to process huge numbers ol' transactions (one for every trade, steal, 
plunder, or take), aiul require that the game servers certify that each involuntarv trade was 
legal (to guard against fraud or hacking) All this network traillc must occur \n reai-time, or 
at least with an asynchronous capability But that asynchronicity can propagate to any depth, 
since objects may rapidly change owners again before a prior ownership transfer has com- 
pleted This quickly leads to a large "roll-back*' problem that a game server must handle on its 
own. 

2 I'hc "S{fnf)/c " Solution 

In some embodiments, to solve the above-described problem, a game player gives a 
20 "power of attorney" privilege to a game server during game play, and rescinds it when the 
game ends or the player withdraws from play. Under these "powers of attorney/' the game 
server takes ownersiiip of every object brought into play, keeping track of the "true" owner 
Tlie game server then runs tlie game according to its rules for who owns what and how they 
got it, and fnially resolves end-game ownership by transferring the objects to their most recent 
25 game-level owners 

During game play, the game server must tag each object with it's current ' designated 
owner," starting with the ID of the original owner The game server still owns the object, as 
far as the Transactor system is concerned, so the designated owner is just a part of how the 
game is played. 'I he tag is simply the Transactor user-ID of whoever has game-level owner- 
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ship ofihc object. Plundered objects are raugetl with the user-ID ol'lhe plunderer. Objects 
traded volinitarily are lagged with the new owner's ID. L.ost or (hoi)ped objects are tagged 
with the Transactor user-ID ol'the game itsell'(/.c.'. the game service provider's ID). When a 
player withdraws and takes his o[)jects out of play, the game server (which owns all in-play 
5 objects) transfers actual Transactor-level ownership to the player if a player's connection 
goes out. the game server maintains the ^'designated owner" tags, subject to plundering by 
other players within the game context 

This arrangement recjuires only that game players trust the game server, which is 
already required as described alxwe No additional trust is required [:)etween game servers and 
10 t ransactor servers All transactions still involve only two eijual parties The Transactor 

server need not distinguish between game-server IDs and ordinary-user ID's, nor treat any 
user in a s[)ecial way 

One downside to this arrangement is that, if a game is played and no objects change 
"true" owners, there is an initial ownership transfer from the players to the game server, plus a 
15 closing transfer back to the original owner In embodiments employing this "siinple solution," 
there is no way to avoid this, because without it the game server has no enforceable authority 
to transfer objects that are in play f ortunately, this activity is largely confined to game 
start ings and endings. 

riiese "power-of-attorney" transfers can occur asynchronously at the begmning of the 
20 game, but players will probably want them to occur synchronously at game-end. Mid-game 
"cash-outs ' that remove objects from play (assuming the game rules allow this) can be 
performed asynchronously, to minimize impact on game play in some embodiments, servers 
spawn sub-processes or call on concurrent server-side programs lo perform cash-outs 
synchronously, rather than burdening the game-program with such non-game details 

25 In some embodiments, a game sen-er provides ''iree parking" to game players who 

want to keep their objects on the server and avoid most uploading and downloading. The 
server retains ownership of the objects, but they are not active in any game. These "parked 
objects" are not available to the player for out-of-game trading, but can be reacquired by the 
player at any time 
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,1. lirokcrs n/n/ Hnf/<cnNiS 

riie teini broker in this description rell:rs to any nuiiually liustcd third party vvlio acts 
on beliairoftvvo oilier parties to elTcct some [)re-detcrniined action. A broker is trusted to act 
on behalf of the original authority, but only within the boundaries defined at the time of the 
5 brokering agreement, and only for specific designated objects In order to actually complete a 
transaction, both participants in the brokered transaction must trust the brokering agent to act 
on their behalf. Thus, a broker is a mutually trusted intermediary in a transaction that occurs 
between two other iridividuals, neither one of whom need inist the oiber 

As described below, a I ransactor Ser\^er provides a means by which an individual may 
10 grant trust to another individual in the I ransactor system This will become clear from the 
following deseription of a "brokering game," 

In a "Brokei ing Game," a broker is an agent. Its actions result in a safe trustworthy 
transaction between twt> other parties, who are the ''players ' in the Brokering Game 

A broker operates on an object, acting as intermediary in transferring ownership 
I 5 between the original owner and the buyer. Users (players) in the Brokering Ganie participate 
voluntarily, and willingly transfer ownership of their objects to (he broker with the itnderstand- 
ing that they will get them back if the broker does not sell the object. 

fhe Game I iniverse of the Brokering Game consists of all the objects that a given 
broker has for sale or trade, and the identity of each object 's original owner (the "designated 
20 owner"). The Brokering Universe may also contain requests by players for the broker to seek 
out and obtain a certain kind or class of object These requests would require a more 
sophisticated Brokering Game program. 

I'iiere may be any number of diflerent Brokering Game Universes running at once, on 
any number of different servers from difTerent providers. They need not communicate with 
IS one another directly, since each is only responsible for its own objects and players (users). 

Any particular instance of the Brokering Game may charge a fee to "play". That is, it 
may charge a fee in order to broker. a transaction fhis fee is diOerent from the Maker's Fee 
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computed by the 1 raiisaclor Server l'"ees are derined hv whoever creates a particiilai' 
Brokering Gaiiic. 

[Jt okers arc typieaily ctMinected throiiuh the Internet to a niunber of other brokers 
(althouuli they need not be) Tliese brokers may communicate requests to one anotlier in 
5 order to complete transactions. These inter-broker communication protocols are yet to be 
defined, but must be standardized for all brt)kers. 

Brokers tliat do not communicate directly with other brokers beliave as simi')le public 
or private store-fronts for the sale of their users' objects (sort of a "consignment store") I'his 
may entail a web connection (HTTP server) in addition to tlie brokering services, or it may be 
10 a "closed game" in which only registered users can log on and participate. That is a decision 
to be made by the game designer it is not a Transactor rule or law 

file basic rules of the Brokering Game, or of any other game which acts as a broker 
for its users, are as follows 

(1) All objects actively being brokered must first have their 
13 rransactor-o\vnershi[) transferred to the broker itself I bis confers the power to 

sell the tibject on tlie brokering agent and have the ownership transferred to the 
buyer immediately, without rec|uiring the original owner to participate directly or 
in real-time 

(2) rhc broker can own objects that arc not actively being 
10 brokered because one or more criteria of the brokering agreement have lapsed 

For example, an agreement may place an end-date beyond which the object cannot 
be sold. Since the user vvili probably not be logged in at that exact moment, the 
broker must immediately take the object out of active brokering "play", and hold 
it in ''parking" or ''escrow" until the user reclaims the object. The broker can't 
-3 simply email the object back to the owner, because the owner's keys are required 

for the ownership transfer. 

(T) Players must trust the broker to return unsold objects on 
demand, or according to .some predetermined criteria, such as after an expiration 
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date This i cc|uiics that the broker keep a roct)rd of the oriuidal owner, along with 
all necessary relevant Transactor information about the owner, and the criteria of 
the brokering agreement The broker must return these objects as requested by 
the original owner, as authenticated by a transactor Server. 

5 (4) Brokers must notify tlie original owner with all due haste 

when an object has been sold, 'fhis is more than just a courtesy to players, since 
tlie original owner may be a game server that requires some real-time notification 
of a sales transaction in order to run its game in something approaching real time. 
Brokers should also notify the original owner when one tif the limiting 
10 criteria of the brokering agreements lapses, when the brokering agreement itself 

expires, or some other criterion takes the object out of active brokering 'play " 

I he basic rules of brokering given above defnie a lundamental set of groiMKl rules by 
which brokers act for users. But tliey are not limited just to game servers that only play the 
Brokering Game. If d///v' game implements these rules using a game-as-broker design, it can 
15 act as a broker on behalf of all its users, for whatever purpose the game designers choose 
One important such purpose is to implement "()lundering'' (also called "stealing'') and 
borrowing within a Game Universe 

J^hindcnny; is a game rule that allows a game user to gain ownership ol*a I ransactor 
object simply by taking it (possession ecjuals ownership). Normally Transactor objects are 

20 useless to those who would simply take them {i.e. copy the file), because the object itself is 

encrypted under the owner's key, and because a Transactor server would disallow the object's 
use except by the owner. If, however, a game universe acts as a broker, then it owns all 
objects that are in play, and no T ransactor server is needed to "change owners" Instead, the 
game servers maintain a "designated owner," which starts out as the object's original 

25 Transactor owner, but may be altered according to the game rules for plundering when 

another user encounters the object. Since the game server is acting as a broker, the player 
who brings the object into play must voluntarily transfer ownership to the game server, fully 
agreeing that the game-play rules determine who will eventually get actual Transactor-certified 
ownership of the object, [f the game design allows objects to be taken out of play, then the 
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must recent ''dcsiyiuitcd owner" receives actual Transactt>r-certiliecl ownership oI'Lhe object, 
and receives the object from the L;aiiic-as-broker, not ironi ilic object s oriuinal owner. 

lyorrowiny, is a game rule or rules that defmc how an object may be used by someone 
other than its owner, and perhaps how ownership of the borrowed object may be transferred 
5 without the owner's direct permission. should the borrower "lose" the object. As with 
plundering, the game server acts as a broker and actually owns the object as far as a 
Transactor server is concerned, f hus, any rules that the game designer makes will be carried 
out on objects already owned. Also as with plundering, there is a "designated owner'' who 
can take the object out of play and become the "actual ovvnei {i.e. the rransactor-certified 
10 owner). A borrower would tvpicallv be prevented from taking the object out of play by the 
game rules. If this is not done, then there is no diiVerence in fact between a borrower and a 
plunderer (since possession would ec|ual ownership), and a borrower would simply be a 
plunderer lo whom you gave the object voluntarily rather than involimtarily. 

Other games that itwolve brokering comprise the following: 

15 ( 1 ) Sales: More than just a neutral broker, a Sales agent would earn its fee by actively 

seeking out buyers for the goods it has been charged with selling. I .ike any broker, it owns 
the goods it is trying to sell, at least according to an authenticating I'ransactor server Tiie 
"designated owner" is the individual who wants the gt)ods stild, and to whom ownership will 
revert according to the agreed-upon rules and constraints, should the item not be sold. 

20 (2) Collectors and Searchers: A collector agent would seek out sellers of goods 

described or designated to it by its users. It would then buy or trade to acquire those goods, 
according to the instructions it was given by a particular user A Collector agent may have 
several users who all want the same object The arbitration rules for deciding who actually 
gets an object are for the designer to define. They aie not a I'ransactor law or rule First- 

25 come first-served is one example of such a mle Highest tlnder's-fee is another. Bribery 
might be another These are all valid Collector rules in the Transactor tmiverse. 
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{} ) GanibliPLi/Cjaniiiig A casino cir uamblinij; house acts as a broker for its patrons It 
may charge a I'ee, or it may take a cut of winnings, or any otfier arrangement The objects 
wagered can be private currency or barterable objects, depending on tlie house rtiles. 

The above rules of brokering can be altered to give difVerenl iimdamental play 
5 experiences l*or example, if the ''designated owner" concept was eliminated, then all objects 
brought into play would be in one large pool of tmowned objects, A raflle or other gambling 
situation might then distribute objects based on some game-play rules, or just randomly, bi 
this game, players would be willing to relinquish all ownership claims to an object in the hope 
of getting some better object brought into play by someone else The game broker would 
10 retain ownership of all tniclaimed or unwanted objects Users would have no expectation of 
getting any of theii own objects back. 

Some brokering agreements may ignore the ' return on demand"' rule, and only return 
objects to their owners when the brokering agreement expires Certain commercial oj)erations 
such as auctit)!! houses migfit need this rule variation, to guarantee to bidders that an object 
I 5 remained ''in play'' until all bids were in or the brokering agreement expired This w(uiid apply 
for real-time as well as delayed auctions. These agreements will also probably have a 
minimum price that the object must be sold for, just as real-world auctions do 

Sei'\'ices, Capabilities and Siipf)oit Modules 

Services, capabilities, and support modules used in an embodiment of a Transactor 
20 system according to the present invention are set forth below, along with a description of how 
these elements interact to produce the desired outcome. 

It will be apparent tt) those skilled in the art. based on the present disclosure, that 
embodiments of Transactor server and client software may be implemented in manv computer 
languages such as, for example, C/C f"^- or Java, and that embodiments may be implemented in 
25 a manner that is portable across Window/Windows NT and selected UNIX environments 

I TrciNsac/or FJcmcnls and Services 
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A I'ransacior syslcni acoorciinu to the present iiivcnlion can be broken down into 
several elements and services. I'he primary division is into client-side elements (termed tools) 
and server-side elements (termed services) Some elements, such as embedded aj^piets, can be 
viewed as lying somewhere between these \ \\'o elements, because they originate from and 
communicate with a server yet run and operate on a client machine. 

A tool is a distinct identifiable program or capability residini; on a client's com[iuter. It 
is invoked directly by a user to accomplish a specific purpose. It is more hke a tool in a Word 
toolbar, rather than like a command-line tool in Unix. 

Publicly accessible server-side elemeius appear simply as services on a network, with 
no specific requirement that liiey be implemented as separate server processes on a particular 
server macliine or cluster of machines. A particular service may be provided by a class or 
thread within a single server program, tir by a distinct server process on a machine, or by a 
group of server machines, o\ even or by a distributed self-updating service like the internet's 
Domain Name System (DNS) As long as the client users and other servers know how to 
obtain tlie service, the details of providing it can vary. 

In addition to supplying or integrating witli I iansactor services, a typical I ransactor 
merchant will also need to supply other conventional vendor services as appropriate (t'.^tT-, a 
sales mechanism or metaphor, a stocking mechanism, billing) 

2 Tnuisactor (licia-SiJc Tools 

20 I ransactor client-side tools, discussed below, reside on and run from the client's 

machine. Preferably, they are not embedded in web pages. A wide variety of techniques for 
constaicting the below tools will be apparent to those skilled in the art, based on the present 
disclosure, 

(a) Object Manager: The object manager collects objects into lists and groups, 
25 examines or browses objects, including unowned ones, etc. I'his is the "root'' Transactor tool 
from which all other actions (owner acceptance, wrapping, unwrapping, etc.) can be per- 
formed. 

25 
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(b) Owner Accepioi The owner acccjHor ncccpls a password or pass-phrase 
typed in, applies it to a Transactor "keychain'", and allows use of resulting Transactor keys, il* 
successful. Ill sonic enibodinients, this tool is iniplemented as an inherent part of the Ohjoct 
Manager. 

-'^ (c) Object Trader fhe object trader enables an accepted owner to engage in 

object trading (selling or l)uyiiig) directly with another Transactor user. In some embodi- 
ments, this tool is implemented as an inherent part oTthe Object Manager. 

(d) Wrapper; The wrapper wraps a raw digital object ( which may be an existing 
digital object in the user's possession or a digital object newly created by the tiser) with an 

10 owner's Transactor info, resulting in a I ransactor object. 

(e) IJnvvrapper: The unvvrapper unwraps an owned object, resulting in a raw digital 
object and a separate file holding the data from the Transactor fields. 

3 Transaaor Sen vr-Sic/c Services 

'These services are provided to both end-user clients as well as to other distributed 
15 servers that need intermediate access to the service (i.e. vendor-servers subscribing to the 
lYansactor services) A wide variety of technitjues for impienienting the below services will 
be apparent to those skilled in the art, based on the present disclosure 

(a) User Registrar: The user registrar register new users, issuing Transactor 

lD\s(TID\s), 

10 allows registered users to edit their info: and respoiuis to a ikxokkeeper's requests to validate 
TlD's. It does not validate objects or ownership, only the identity oi' users. 

(b) Bookkee|)er: The bookkeeper receives, confirms, and logs all transactions 
and transfers of objects; maintains accounts (distributes splits to other users, etc.); and 
performs collect-and-forward transactions to other mercantile seiA^ers (bank-cards and bank- 

5 deposits) 

(e) Object Registrar; The object registrar register new objects, issuing Object 

ID'sfOlD^s), 

26 
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validates Dhjccls and owncisliip llicrcof, foi Bt^okkccpci ; and performs (uvncrship transfers in 
support of Bookkeeper 

4 I cnclor \\ Scrvcf -Sic/c Scf \'ic(:.\ 

In some embodiments, a Transaclor vendor will have utilize a Storekeeper 
service, which keeps an inventory hst, keeps a sales log of transactions, and communicates 
with the User Registrar, Bookkeeper, and Ohject Registrar. 

(a) Transactor Support Modules: 

I'he above tools and services are built upon a common set of support modules. A 
module should be treated as a related set t)f facilities or capabilities, not necessarily as a 
software-design element correspondnig to a library, package, or class The ct>rc support 
modules are; 

Database Module 
Cryptography/Security Module 
fransactor-field Module 
Logging Module 
Financial Module 

Not all client-side tools or networked services will use every support module, but they 
all use the same module whenever there is a need for shared data For example, all parts of 
Transactor use the same cryptography and Transactor-field modules (and the same revision- 
level thereoO, otherwise any exchange would appear as gibberish to one side or the other. 

Networking software may be provided either as a standard library (c.i^r, as for C or 
C++), or as a standard part of the language system U^..ir., as for Java). 

(b) Database Module: 

/VII information about transzictions, users, objects, etc. is kept in databases. Because 
some information is very valuable or sensitive, while other information may change at a rapid 
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rate, several actual databases prelerahlv are niainiained. railier than a siiiiile all-enct)inpassii)g 
database. 

(c) Cryptt^tj^raphy/Securiiy Module: 

riiis module is responsible for encrypting and deciyptiny all Transactor objects and 
5 communications. It is also responsible for generating unique cr^/ptography keys. Transactor 

id's, and Object ID's. I-inally, it validates a password or |)ass-plirase entered by a user to gain 
access to the Transactor ''key-chain file (i.e., it provides chent-sidc key-management 
functions). 

(d) Transactor-Field Module 

10 This module allows other modules to read or write the 1 lansactor fields oi\i given 

object's Transactor wrapper independent of any actual game or otlier use Tliis module also 
performs wrap and unwrap of raw digital objects. 

(e) Financial Module: 

Using the values from an object's I'ransacior fields, as received from the Transactor- 
15 Field Module, this module computes sphls, fees, etc. for all the participants in a sales transac- 
tion according to an object's predetermined Revenue Model This module also distributes 
those amounts to each user account in the database, and writes entries in the log This module 
also interfaces to third-parly "bankware" to perform payments and billing of all user accounts. 
A policy is defined so as to determine when, how often, at what amount, what activity level, 
20 etc. to actually initiate a banking transaction involving the bankvvare. 

A Revenue Model is a server-side software element that determines how revenues 
accrue to Owners, Makers, etc in some embodiments, it is preferable to define several 
standard Revenue Models . In some embodiments, a "plug-in" type architecture for additional 
Revenue Model components is also used 

25 (f) Logging Module: 
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A log provides a coiiii>lctc scnali/cd list of every cluiiiLic to any 'i'ransactor database. 
This acts not only as a backuii in case t>r database corruption, btit also as an independent 
accounting audit trail ibr all transactions. Fhe Logging module maintains several such togs, 
serving dillerent purposes as outlined in more detail later Most logging occurs on the servci- 
5 side, but a client-side Logging Module is responsible for logging a user's transaction histtuy ">i 
the local transaction log I'his is purely for user iniormation purposes. 

Additional f catiires of [Vlodiiles 

i . Ihc Crvixos^raphy Sciitriiv Modiite 

Cryptography provides several features within Transactor: data invisibility, data 
10 integrity, authentication, etc. I.kiut invtsibility means that the data is not visible to any but an 
authorized user/owner I'his is accomplished with encr\'ption. Data intc.{^rity means that data 
can be determined as being in an untampered I'orm This is accomplished with secure hashing 
and digital signatures Anthcnticadofi means that two parties who do not tnist each other can 
each determine that tlie other entity is who it claims to be This is accomplished with 
I 5 authenticating protocols that may emplov encryption, hashing, digital signatures, etc. 

This module is responsible for encr>'ption and decryption of objects and other data, as 
well as creation of cp^'ptography keys, A Transactor ID and an Object ID are part of the 
autiicntication system and, preferably, are uniquely identifiable and cryptographically secure. 
User ID s may simply be sec|uentially assigned numbers, from a pre-determined range allotted 

20 to a particular fransactor server Uniqueness is the only requirement. Object ID's may 
include a sequentially assigned number, as well as hashed information about the object's 
contents, maker, registration time, etc These values are essentially impossible to forge or 
fake, nor do they allow an altered or forged object or user to be improperly recognized as 
valid. Since tiie user and object databases contain every known ID, all objects and users can 

25 always be verified. 

A Transactor user's data may cliange over time, such as from a change of address. 
This does not alter the originally issued Transactor ID The registered user simply enters the 
new data, while using the same ID originally calculated and assigned. 
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A I raiisactoi object docs noi chanuc over tunc, so its Ohjecl ID (or a related message 
digest or hash) can always be recalculated to verity that it has not been tampered with. This is 
how objects can be verified as unaltered even without iranslerrinu their entue contents to the 
Transactor Bookkeeper service. 

S The fact that objects are, in this sense, immutable once registered does not prevent 

time-varying |}roperties troin accruing to the object, it only prevents tiiat variable property 
from being verified by the Bookkeeper For example, a game weapon may have a variable 
power level, but that variable must be kept outside the ''vvrap[)er" provided for Transactor 
object validation. Tiic weapon itself may define internal constants that limit valid power 
10 levels, and these wotild be inside the wrapper to prevent tampering Thus, the worst eilect 
from tampering is to gain a full power level. 

One variable property that the Bookkeeper elites track is existence (c.i^r was the object 
destroyed) Destroyed objects are still kept in tiie database, but are marked as destroyed (or 
arc moved to a separate "destroyed" database). This makes such objects recognizable but 
1 5 unusable. An administrator may enact a rcfircmcni policy that removes the majority of a 

destroyed object's data after some period of lime, to keep database size manageable As long 
as Object ID's, message digests, or hashes are retained so an object can be recognized as 
destroyed, the object^s entire original data-package need not be preserved. 

2. Tiw Iratisucior-I'icld ^ iodulc 

20 Every t ransactor digital object preferably contains several data (lelds in the object 

itself that identify the object and its owner, its original creator, the revenue model, and how 
sales splits are computed. The Tran,sactor registered-object database holds the correct values 
of all unalterable fields, so any tampered field can be easily identified and set right. 

Other Transactor modules use the Transactor-field values to determine how to handle 
25 the object, or how to handle transactions involving the object. This module provides uniform 
access to all readable fields, and constrained but uniform access to writable fields. For 
example, anyone can read the Current Owner field and retrieve the ID kept there, but only the 
accepted and verified owner can write to that field. But even the owner can't do everything. 
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An owner can set a new price, but can't ehanue llie Maker or Split fields. The latter can only 
he changed by the oriuinal Maker. 

3 . The I'ifhffiCiul Module 

The Financial Module acts as the intermediary between fransactor transactions and 
5 actual banking or paymcnt-systeni (bankvvare) transactions. This module's main purpose is to 
calculate aiid distribute the fee splits designated by the object being sold, in the simplest case, 
tills is basically a "calculate and forward" module, and every Transactor transaction immedi- 
ately results in one or more bankvvare transactions. Such a simple implementation might not 
even need to keep any account-balance information of its own, instead relying entirely on the 
10 bank-maintained accounts to determine a user's balances. 

A more sophisticated Financial Module might instead maintain its own ^summaiy" 
accounts lor every user, and only perform bankware transactions at the end ol'thc day, and 
only tor those accounts whose resulting daily balance was larger than some prcdefmed amount 
(c.ii. more than S2 00 credit or deficit), or had gone longer than 30 days without a transaction. 
I 5 By aggregating the bankware transactions in this way, users and vendors are sj)ared the 

overhead of large numbers of tiny banking transactions. The detailed transaction logs and the 
corresponding reporting tools provide a complete audit tiail to determine every detail that 
went into any aggregated banking transaction. 

In SLich a "summary account" system, the user's current account balance is either a 
20 positive or negative amount At the end of each day ( or other policy-defined billing period), 
the current balance is zeroed out, and translated into an appropriate credit deposit or debit 
charge against the user's designated outside financial accounts. That is, a single bankware 
transaction occurs. If the amount is small enough, it is simply carried forward to the next 
billing period and no bankware transactions are performed for that user's account The 
25 precise details of ''small enough", as well as other particulars such as a small balance carried 
for a long enough period of time, will be determined by further research or an arbitrary 
decision in the design. In any case, these parameters must be tunable. 
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riierc arc iulvanlaucs and tiisaclvantaucs to any particular I*inancial Module design, 
anywhere along the continuum between the two [)ossible methods presenled above These 
benefits and risks must be completelv enumerated a!id analyzed in (iirther hinancial Module 
design In particular, issues of security, expected server load, and customer or bank liability 
5 will be considered, along with any legal or financial responsibility requirements 

A Revenue iV/ocfc/ is a software element that calculates how ownership transfers 
generate revenue for sellers or makers, A Kevenue Model is designated by an ID in the 
I ransactor object itself, designated when the object was created by its maker. I'he Revenue 
Model software component is passed information about the object, the sale price, etc and is 
10 responsible for calculating how much of the sale price goes to seller, maker, biH)ker, etc 

These values are then returned to the main Financial Module for actual disbursement, fhus, 
the Revenue Model software component has no knowledge or interaction with accounts, 
bank ware, etc It only calculates shares in a revenue stream. 

fhe above variations in undei lying design should not be interpreted as uncertainty in 
1 5 the Transactor design or bankware interfaces. Rather, they should be treated as available 
options (^r modules determined either by the vendor who installs a Transactor system, or as 
required to support difTerent payment options that may operate under dilTerent constraints 
(t'.^r, credit-cards, debit-accounts, DigiCash) 

4 7 he /y>i:e/;/e Module 

20 Depending on the capabilities of the database selected (for example. Oracle), most data 

collected and processed by the diflbrent Transactor services is kept in redundant form, fhe 
primar\' storage iacilities are the various databases Redundant information is kept by time- 
stamping and logging every transaction that alters any database This log acts as both an 
accounting audit trail and as a backup mechanism. 

25 As an audit trail, the log can be searched (otT-line using yet-to-be-detined tools) to 

discover reasons for problems like, for example, account balance disparities or contested 
purchases. U also clearly shows the time at which each transaction was made. 
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As a backup niccliaiiisin, llic log can be used tt) restore ihe daUibascs should they 
become corrupted. This is accomplished by starting with a valid backup database and 
sequentially applying every logged alteration. The result is an up-to-date database In the 
safest setup, all log tiles are kept on a diHerenl physical hard disk than the database liles, 

5 Note that separately implemented togging facilities may be eliminated as redundant, as 

fault tolerance services of the Oracle database may more easily or simply meet these require- 
ments However, the logging module is nonetheless described here to illuminate the- required 
functionality 

Rules (>r L.ogt;ing 

10 • Log-files must always be secured — they hold sensitive or valuable data 

Data is only ap|.>entled to a log-file, never deleted 

Eveiy log-entry is automatically time-stamped with its entry-time into the log. 
Every transaction is logged, both valid and invalid ones 
One log entry may correspond to several changes in the databases. 
I 5 • Log-file formats should be compact (i.e. binary, not ASCII text). 

Note that even rejected transactions are logged, since they indicate some kind of 
problem (data loss, theft attempt, etc ), To prevent the log file from growing too large, the 
Loggmg Mt)dule can switch to another log-file at any time, under administrative direction 
(manually, at a scheduled time (c^^l,^ midnight), etc ). A log-file switch is performed using the 
20 algorithm outlined below Log entries received during the switch are queued up and eventu- 
ally written to the new log-file. The logger must never overwrite, tmncate, or delete a file 
itself [fit fails to create a new empty unique log-file, it will refuse to switch log files. 

Log-files need not be kept forever. They can be moved olY-line after some period oi" 
time and retained only until their backup media is reused. The scheduling of this should be 
25 one of the policies determined by the Transactor administrators or owners, and implemented 
as a configuration option of the Transactor software 
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Since log-lilcs conUiin valiial)le sciisiiivc data, tlicy must lie kept secure at all tiiiics, 
even vvlien olV-line Lou, files may be cncPy^ptcd to |irotecl ayainst possible snuopiny. Tliis 
option must only alter the data written to the k)y, not any other aspect of its nature 

5 Los:- 1 • ilc S\ \ ifcl lo 1 'c/ • 

5 A log may be 'reset' so that log-filcs do not grow too large. This does not actually 

delete any data from the log Instead, tlie l(^ggcr switches to a new log-lile, leaving the prior 
log-fde intact. Failure at any point aborts the log-switch, and Itigging continues in the original 
file, with a log-entrv' made that a log-switch failetl fhis switch is accomplished as follows: 

0) a memory- based queue is created to hold log-entries received during the 
10 switch nmries are time-stamped with their entry-time into the queue. 

I ) a new file is created tnuier a temporary name It will be automatically renamed 
after a successful log-switch has occurred. Failing file creation, no log-switch occurs, so stop 
now 

2) On successlid file creation, a transfer time-stamp is made I'his time-stamp 
15 will be used in several following operations 

3) A "transfer entry" is written to the new log file, stamped with the transfer time- 
stamp 

4) The prior log-file is written with an identical 'transfer entry'\ and the file is 
Hushed to disk, 

20 5) The prior log-file is closed. 

6) The prior log-file is renamed by appending the transfer time-stamp to the 
existing name, in an acceptable ASCII format (/.c, no illegal characters fiir the machine). 

7) The new log-file is renamed to the old log-fde s name. Depending on the 
platform, this may require closing the new log-lilc, renaming it, then reopening it and seeking 

25 to the end. 

8) The new log-file is written with a "linkage entry" noting the new name of the 
prior log-file This enti7 is time-staniped with the actual time of log-switch completion, not 
the earlier transfer time. 

^y) All queued log-entries are appended to the new log-file 
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Ai'tcr coniplctioii oftlic above steps, the old loij;-liic can be niovetl olV-line, or to 
backup media, or whatever. New log entries will be appetided to the new log-file, which starts 
out with at least two entries the transfer entry and the linkage entry. Any log-entries received 
during switchover are also in the new log-file. 

5 rnnisactions and transaction Records 

A Transactor irafisncHon occurs whenever ownership of an object is tr ansferred from 
its current owner to a new owner A trtmsacfion record is the collection ol data that describes 
all the entities involved in lliat transaction and the type of transaction requested. Transaction 
records can be valid or invalid, solely depending on their contents A critical Transactor 
10 service is to recognize and prohibit all invalid transfers by rejecting invalid transaction records. 
It is the Bookkeeper that performs this service, with support from the Object and User 
Registrars 

A transaction record basically looks like this: 

Type: Seller sold Buyer this Object on Date lor l*rice, hy time X; signed 
I 5 by Seller, then Buyer. 

This directly translates into a data representation format: 

1: S sold B this O on I) for \\ by \; signed: SS, BB. 

T is the type of transaction record, identifying the rest of the data for the Transactor 
server S is the Seller's TID, which must also be the original owner of the object. Y^ is the 

20 Buyer's TID, which will be the new owner of the object. O is the transferred object's unique 
Object \ D (01 D), or some yet-to-be-determined unforgeable token representing the object 
itself (^:^^^^^ a message digest or secure hash). D is the date and time (expressed in GM T for 
uniformity ) at which the transaction occurred. P is the agreed-upon price, if it was a sale for 
money as opposed to barter. X is an expiration-time a short time after the transaction record 

25 is completed. Its purpose is explained below. The entire transaction record is then digitally 
signed by the Seller SS, then by the Buyer BB. This collection of data is then sent to the 
Bookkeeper service for validation and approval. If approved, the given object's ownership is 
transferred to the buyer, and the new ownership is recorded in the database. If rejected, there 
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is no ownership transtl-r, but the nookkec[)cr retains the record so it can detecl palterns ol^ 
fraud or other dilliciikics 

l he Seller constructs the transaction record and Hlls in all Fields, then signs it. Tlie 
transaction record is then sent to the Buyer, who decrypts it, vcrilies the Seller's signature, 
then signs it, encrypts it again, and sends it to the Bookkeeper service. These last steps 
requires the Ruyer^s cooperation, so the Seller must trust the buyer to actually sign and 
forward the transaction record. Without the expiration-time X, this would be a security flaw, 
since Seller s are not required to trust Buyer s. Adding an ex[)iration-time declares a deadline 
after which the transaction record is automatically invahd, so the Seller is no longer entirely 
dependent on the Buyer's good behavior. The Buyer must submit the transaction record to 
the Transactor server before tiiis deadline, otherwise it will be rejected, even if all other data is 
correct fhis deadline prevents the Buyer Irom holding the Seller's objcci 'hostage ' for an 
indeterminate time, ellectively preventing its sale or use elsewhere. After the deadline, the 
Seller can sell the object to someone else without fear that a bogus delayed transaction record 
will be sent in by an unscrupulous Buyer A short deadline {say 30 seconds) can be used as 
the initial time-out, but if network delays cause rejection, this can be automatically increased 
by some increment up to sonie reasonable upper limit (say 3 minutes) that both Seller and 
Buyer agree on first. 

Because both the Buyer and the Seller sign the transaction record witli their private 
digital-signatures, neither one can later claim ignorance of the transaction and demand that 
ownership be restored (i.e. the protocol provides non-repudiation). If either one delects 
cheating or itnproper data using its own knowledge, it can simply refijsc to sign the transaction 
record Both signings are voluntary. 

In preferred embodiments, rather than validating individual users or objects, only entire 
transaction records are validated. If any part of the transaction record is invalid, the entire 
transaction is rejected and a reason returned. If the complete transaction is validated, then 
approval is given, and the clients then transfer the data. 

When a transaction record is rejected, it can be for various reasons. Invalid ID's for 
any participant is one reason, invalid signatures is another, and unintelligible data is yet 
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another. Sonic reasons nuiy be eniharrassinu Cor either Buyer or Seller, such as ' insulVicient 
liinds", so not aii reasons for rejection arc sent to the chents, only some. A detailed design 
must list all rejection reasons and which are sent to clients. 

When a transaction record is accepted, tlie Bookkeeper tells the Financial Module to 
> calculate and distribute sales splits, lees, etc It also tipdates the object and ownership 

databases to reflect the resulting object transfer Ail intelligible transaction records, whether 
accepted ov rejected, are logged to a transaction log-filc Certain patterns of rejections may 
send a security notification to an administrator, or take some other |)rcdefmed action, CJarbled 
transaction-record attempts are not logged to the transaction log, but may append an entiy to 
10 a "problem with host 11" file for later perusal and action by an administrator. 

I Identifyinu Authentic Objects 

The value of O in a transaction record must be something more than just the OlD of 
the object. This is to prevent various fraud schemes whereby having an object's ID would be 
ec|uivalent to having the object. One way to avoid such problems is to have the O value be a 

15 collection or composite of several values that not only identify the object, but also act as an 
assurance that the object is really in S's possession, and really owned by S. One part of this 
composite is the OH), fhe "assurance value" needs to be something that can only be 
calculated by the object's tiiie owner, such as a message-digest of the object's decrypted 
contents (only possible for the owner and the Bookkeeper) combined with the values for B 

20 and D to introduce unpredictability Without the unpredictable values of B & D (and perhaps 
some other random strings), a cheater could have precalculated the object's message-digest, 
and it would never change even after the object was sold or destroyed. Thus, the main reason 
for using a message-digest would be lost. 

2. Transaction Types 

25 Although entire transaction records are the only thing validated by the Bookkeeper, 

each transaction record has a type identifier in it, and certain idiomatic patterns of data in tlie 
records. Here are some obvious forms, although there are probably more that are useful. 
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All tlio (lilluwinij; patterns have iciiotnatic values deliiied in ilie transaction record 
formed as: 

1: S soil! B this O on I) lor P, by \; sigiKil: SS, \Ul. 

Otiiy the idiomatic distinctions are pointed out, vvliilc all other fields retain their normal 
meaning. In particuhu\ the D field always contains the date/time of the retjuest, and the 
contents are always sijj^ned by at least one participant. Some lields have no meaninij; outside of 
sales transactions, such as tlie price W vvhicii is /.ero on all the following. 

/ 'cn/v (I User (TID) S is the user making the request W is the TID being checked O 
IS all zeros The record is only signed by SS. An "OK'' response means that B is a valid TID 
llcjection may mean any error 

f ci/ic/iifc an Owned ( )h/ccf S equals B, and is the user making the i ec|uest O is the 
object identifier/digest. The record is only signed by SS An ''OK" response means tiiat the 
object is valid ant/ is owned by S Rejection may mean any error 

f \iliclate an I Inowned Ohject S is all zeros. B is the user making the request. O is the 
object identilier/digest. The record is only signed by BB An ''OK" response means that the 
object itseli'is valid, but /7.v ownership is nnc/eferniinec/ This prevents non-owners from 
inferring another user's owned objects by probing with valid Object ID's Rejection may mean 
any error 

Special Object Properties aiul Situations 

The Transactor software system is a flexible general-purpose system for estabhshing 
ownership and for conveymg products and payments It is not limited to real-world monetary 
transactions, nor to purely digital objects. Following are some specialized features that are 
available, in some embodiments, as options to Transactor service providers. 

I Preview Objects 

When an ordinary user is offering an owned object for sale or trade, it is useful for tlie 
buyer to examine the on-screen representations of the actual object (i,e. its image or sound) on 
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liis own iiiachiiic Tlicse may l)c beauty shuts or the actual images that are part of the object, 
tt c/ac.s Nif/ inchide any of the object 's behaviors, h(nvever 

These previews are one use of a special property tliat can be given to a Transactor 
object: the frans/cnf property Transient objects provide a mechanism to allow exchange of 
S data between users or client and server that exploits the security and consistency of the 

Transactor protocols, while noi transferring owncrsliip or utihty to the receiver. Transient 
objects cannot be stored in a user's iiwentory. and they automatically disa|)pear when the 
connection with their originator is broken. 

To create a previewable object without transferring the entire real object (which could 
10 be much larger), the original complete object may contain or refer to a small embedded 

transient "preview" of itself which can be separately extracted and sent to tiie prospective 
buyer Hiis transient object has no value, is unusable in play, and cannot be traded or retained 
in the user's inventory It is purely for examination before purchase. Its Object ID does not 
exist in any Transactor-server database, since it is created on-the-tly, so it cannot be traded 

1 5 Not ail Transactor objects must contain previews Tiie user may already have all the 

previewable images or elements possible for a game or other scenario (^.'.^^ on the original CO- 
IIOM), and it would sulllce for the buyer to know that a Model X4 1 Laser Pisttil was being 
offered The soltware would then load the previewing images or other representations from 
the buyer's local machine (hard disk oi CD-ROM), and no preview object would be needed 

-^^ 2 Membership Cards 

In principle, a membership card is a persistent "entry visa" to other services or 
privileges It is persistent in that it cannot be spent or expended like currency, and has no 
inherent value as currency (but may have collectible value). It allows entry or access to 
services, because the service provider can see the user present a valid card . Membership 
25 cards usually have an expiration date, nor are they transferable to another user except by the 
issuer. A passport is one example of a "membership card", as is a driver's license. 

A membership card also identities tiie holder as a member of the issuing organization, 
but this is primarily for use by other organizations, since in an electronic world an organization 
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may he presiinicci to liavc an available database ornicinbcrs, makitiu tiicnibcrship cards 
SLipcrlluotis. As a real-world example, membership cards may be used across organizations, 
such as showing a specific airiiiie's rrcc|uent-(lyer caid to receive a discount at a particuhir car- 
rental ageticy The cai-rental agency can't redeem miles, btit can give a discount after seeing a 
valid card, 'fhus possessit)n of the card has value, even if not as currency. 

Membership cards are one application of a special property of Transactor objects: the 
a.ssii^ncJ property. An assigned object is owned like any other Transactor object, but its 
ownership cannot be changed by the owner, only by the maker/issuer. Specifically, tlie 
assigned object cannot be sold or traded away until after it expires (thus not interfering with 
any potential collectibles market) If the issuer creates the object with an expiration date, then 
the object is only valid until that date 

All assigned objects contain the normal I ransactor helds identifying the owner, maker, 
etc. But since these llelds are inherently alteral)le, the assiuned object must have an override 
mechanism, fhat override is contaitied in the digitally-signed and inherently unalterable body 
of the object It consists of an additional packet of data labeled as "assignment data" and 
appearing in a standardized form, which contains the TID of the issuing organization, the TID 
of the assigned owner, and an a,ssignment expiration date These unalterable fields automati- 
cally override the normal Transactor fields, and thus prevent the object from being traded 
away or transferred. Since the issuer and assignee TID^s are visible, the user's membership in 
that particular issuing organization is confirmed to any third party who requests a membership 
card. 

The assignment data packet may also hold an expiration date. When used bevond that 
date, the object is no longer valid, and should be treated as if the object did not exist iH)r the 
case ol membership cards, this represents the membership expiration date. Tor other kinds of 
assigned objects, it may represent a deadline or some other hxed date or timestai7ip, as defined 
by tiiat kind of object's unique requirements. 

Membership cards may be defined by the issuer/maker to hold preferences or other 
demographic data about the assigned owner This data may be encrypted, visible only to the 
issuer, or it tnay be cleartcxt, visible to any organization that the card is presented to. In the 
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rc:il \vt)i ki, ibr example, driver's lieeiises arc enbclively nieinbersliip cards. A "motorcycle" 
endorsement or "correcLive lenses" restriction are owner-S[iecilic information encoded on tiie 
card itself. 

} Private Currencies 

S A privafc ct/rrcncy is any fungihle valuable medium of excliange that does not 

represent actual money. The term /////v/A/c means that the nature of the object makes it 
replaceai)le and non-unique, such as Lorain or cash is in tiie real world 'I he term vnhuihlc 
simply means that people might have a reason to collect pieces of the exchange medium, other 
than as collector's items. So private currencies do have real value, even if not directly 
10 convertible to cash. Some real-world examples aie frec|uent-llyer miles that accrue and earn 
airline tickets or hotel stays, or the *'bcMUis points " awarded by some long-distance phone 
carriers that can be redeemed for phone-time or merchandise But perhaps the best -known 
example is ScK:I I green stamps — they are fungible and valuable, but have no actual cash 
value. 

13 When a fransactor system is installed, its mediimi of exchange is defmed as either 

money or a private currency. If the private currency option is chosen, then a 
CurrencyConversion supporting module is configured and installed in tlie system. This 
module converts private currency amounts into money amounts, as needed by other modules 
in the system (c.\^. the billing department) The actual conversion data is defined in a vendor- 

20 specific database, which is kept secure on the vendor's servers, and can be edited by the 
vendor at any time. 

A private-currency Transactor system recjuires conversion into and out of the private 
currency Conversion into private currency is made as a money-purchase of some number of 
units of the private currency. For example, a user spends S 10 and has 1000 quatloos credited 
23 to his account. This can be a straight hnear conversion, or it can be tiered (c. t;. spend $20 and 
get 2500 quatloos), all as defmed in the conversion database. 

Normal spending of the private currency is simply a ''redemption" of the private 
currency in exchange for an object. This needs no conversion, only the price of the object 

41 

SUBSTITUTE SHEET (RULE 26) 

BNSDOOD; -.WO.. 994 709 1 A V J 



wo 98/47091 



rCT/US98/(ni76 



expressed in llie private currency, ci^r 200 quatU)os to jnirchase a new laser-pislol digital 
object The buyer" s account is debited and the object is transferred to the new t)vvner. If the 
seller were another user, then the selier\s account would be credited. Nowhere is a conversion 
out of the private currency required Note that this is true even when /;/n*.s7a// objects are 
5 being purchased (c.^:. the example of S&H green stamps did not require cash, either). 

Conversions out of the private currcticy only occur when outside organizations are 
iiwoived. i'or example, if a phone company were olTcring conversion of quatloos at 50 per 
minute of long-distance time, then a conversion would need to be performed. This informa- 
tion is contained in the database, and identifies not only the conversion rate, but the identity of 
10 tiie olferer (phone company ), the expiration date of the otTer, and any other limits on conver- 
sion (not more than 5000 quatloos per individual). All this data is used to perform an outside 
transaction, according to the protocols for physical objects (described next) 

Purchasing IMiysical Objects 

Physical objects can be bought and sold on a fransactor system, in addition to or as an 
15 alternative (o purely digital objects. I'or example, a user can buy a T-shirt or a game acces- 
sory as easily as a new digital game object. The user immediately receives an assigned digital 
object representing the purchase of the physical object, and later receives the actual physical 
object via a shipping channel. Any conventional shipping ciiannel may be used for this 
purpose 

20 The purchase of physical objects requires an interface between the Transactor server 

and a merchandise supplier, fliis is similar in concept to the interface between the Transactor 
server and fmanciat institutions, and is accomplished using identical supporting software and 
interfaces; that is, the merchandise supplier appears to the system as just another outside 
organization providing "llnanciaf' services. The only diflerence is that the middleware deals in 

25 merchandise orders rather than in monetary transfers. Both types of transactions involve 
transfer of value, account reconciling, security aspects, etc. 

When a user purchases a physical object, his account is debited in the normal way. A 
new digital object is created and transferred to the user. This digital object represents the 
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merchandise order, and contains all the information one would fnid on a leyular order receipt: 
dale of order, price, trackinij; number, huyer, seller ship[)er, shipping address, etc. Thus, the 
digital oiiject serves as a digital receipt The digital object, however, can also contain other 
elements, such as beauty shots of the purchased physical object ic.i^r JPEG images), preferably 
5 rendered to match any optional features, like color or size. This digital object is an assii^ned 
ohfcct having no intrinsic value (described above, under ''Membership Cards"). Since it is 
assigned only to the buyer, it cannot be traded away, although it cati be deleted from the 
owner s inventory at any time, if desired 

When the user s account is debited, an order is placed with the merchandise supplier, 
10 as if that supplier were being "credited" with the amount deducted from the user In reality, 
the "credit transaction" is an order for the merchandise, incorporating all the shipping 
information and other account information needed to process the order At that point, it is the 
supplier's responsibility to ship the order \o the user, and the rfansactor system is not 
involved any further. 

15 This protoc(^l for purchasing physical objects works for any Transactor-supported 

sales mechanism, including direct object sales as well as llyers Fhc tlyer for a physical object 
is no different than that for a digital object, since both actually refer to a service provided by a 
supplier, as outlined above. 

Ci^ptograpliic Protocols 

20 A variety of cryptographic protocols to provide security for the above-described 

rransactor system and other Transactor systems according to the present invention will be 
apparent to those skilled in the art based on the present disclosure. This section presents a 
preferred set of mechanisms and protocols used to provide security in connection with the 
Transactor system discussed above fhese security features are discussed in the context of, 

25 and are particularly useful in embodiments, involving interactive games which may allow 
ownership and transfer of various kinds of objects, both online and offline. 

In the game setting, objects are typically owned by players (in some cases, they may be 
simply lying discarded somewhere, t>wned by no player, in which case ownership may be 
assigned to the game server). An object is not necessarily represented by an '"object" in some 
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prourainminLi language (tliough lliis would be a tuituial way tu represent it) Ganic objcets are 
usually owned by someone, and have speeifie attributes, vvbicli may eliange over lime. 

In some game embodiments, objcets are owned by independent agents acting in the 
game world. This ean be considered, to be a form ol\>wnersbip by the game server In the 
5 vvorldvievv of the players, however, the objects will be owned by another entity. 

Objects and Cliealing 

It is desirable to resist several kinds of clieating, which include 

a. Unauthorized creation-Most objects cannot be created by players. 

10 b. Unauthorized transfer-Some objects can only be transferred under special 

conditions 

c. Unauthorized destruction-Most objects cannot be destroyed by players, or can 
only be destroyed under special conditions 

15 

d. Impermissible multiple transfers-A player may try to transfer the same object 
sec|uentially to many other players, which is inapprtipriate for most objects as a previously 
transferred object is no longer in the first player^s possession. 

20 e. Queries- A player may try to determine what objects are in the possession of other 

players, or those objects' attributes. 

f Unwanted Transfer— A player may try to transfer an object to or from another 
player, without that player's approval. 

25 

g. Resurrection-A player may try to bring back an object that has been destroyed. 

h. Alteration-A player may try to alter the attributes of an object, i.e. increasing the 
number of charges some magic item has. 
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i Multifile Play— A i)lavcr may try to play in tiianv diiVciciu i;aines (in any mode but 
Sci vcr-Modc), and use the same ohjects \u eaeh. I'his is an extension i)f the idea ofnuiltipie 
translers, 

5 The following protocols and data structures allow the Transactor system to resist 

unautluiri/.ed creation, queries, and unwanted transfers at all times All the other attacks can 
be resisted in real-time only in Server-Mode, atid otherwise will allow the cheating to be 
caught later. 

Notation 

10 In this section, several protocols are described using the following simple notation, 

a [/.nci-yjition using a symmetric algorithm, such as DllS, ^^DBS, or RC4. is shown as 
E I Key I (Data), where Key is the key and Data is the data being encrypted 

b I lashing using a one-way hash function, such as MDS or SUA I, is shown as 
IS liash(Data). 

c Public-key signing using an algorithm such as KSA, DSA, or EIGamal, is shown as 
Sign ! PrivateKey l(Data), where PrivateKey is the signer's private key, and Data is the data 
beinu siuned 



20 



25 



d. Public-key encr\'ption, using an algorithm such as RSA or FJGamal, is shown as 
PKLi] PublicKey!(Data), where PublicKey is the public key of the message's intended 
recipient, and Data is the data being encrypted, Typically, this is used only to send random 
encryption keys for symmetric algorithms. 

e All protocol steps start with a header value, labeled something like 
Ul = hash(" Transactor System— Exit V^isa Request"), 
This is used to ensure that both the sender and the receiver always can 
immediately tell which message of which protocol they have received. These can be 
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prccoinpuicd iind stored in the source code :is conslants, or the iictual text string can he used 
to calculate this at run time. 



r. Many protticols reqmre some random numbers or keys. I liese are assumed to be 
coming from a liigh-quality cryptographic random bit generator. Good cryptographic libraries, 
such as BSAFF, KSAKCI', and CryptoLib, have good software routines for starting with a 
random seed value loo unpredictable to be guessed, and using it to derive a long sequence of 
unpredicalable values I vpically, the problem is m getting a suHiciently random initial seed. 
Methods to do this are described in tlic last part of this section. A variety of protocols and 
algorithms are known to those skilled in the art (.svc\ Scheier, Appliecl (^rypf()^ntph\\ 2nd 
I;:dition (John Wiley Ik Sons, 1006)) and, based on the present disclosure, may be used in 
connection with embodiments of the present invention. 

Iiiiplcineiilatioii o( Hie Protocols 

Bich protocol message has a unique 160-bit identifier at its beginning, Ibllowed by a 
32-bil version identifier, and a 32-bit value giving the length of the whole final message. This 
IS intended to allow an implemeruation to parse each incoming message immediately. 

Preferably, there is one universally-accepted message; 

UO hash( "Transactor System— Brror Message") 

VO version 

20 LO total message lengtli 

Ux ^- the header of the previous message 

CO - • error code 

LOa ^ Length of freeform error rccoveiy data (may be zero). 
DO ^ freeform error recoveiy data 
25 XO = UO,VO,LO,hash(prev message *),C0,LOa,D0 



10 
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When ihcrc is no previous nicssaiAC lliis is an all-/.cro field. 

The total niessaue is 

MO - X(),Si<^nJSK 1 Sender} ;(X0). 

As slated below, all lengths are ij;iven in hits (to accomniodale odd lengths of key or 
5 data), hut all fields are padded out with zeros to the next full byte boundary 

f he above described bit fields are examples only. Other enibodinieiUs having dilTerent 
bit fields and protocol iin[)lenieiitalions will he apparent to those skilled in the art based on the 
present disclosure 

Projmiiimniiijj; Models 

10 A variety of interactive game design approaches for use in connection with a 

Transactor system will be apparent to those skilled in the art based on the present disclosure. 
In some embodiments, there is one central server, which holds the "world," and with which all 
players' machines interact to learn about and inlluence their world. This is an inherently simple 
way of implementing a game It sutVers from the problems that it may be hard to find a trusted 

1 S server machine which has the computational ability and bandwidth to and from each player's 
machine to do this elVectively. Hssentially, this is related It) centrally maintaining one big 
database with various kinds of access restrictions The security model described below is 
most cllective in connection with this type o I' game .setting. 

Modes of Pl:iy 

20 This security system relates to the following four basic modes of play: 

(t ) Server-Mode: The most secure design for all of the security issues is simply to 
have eacli player interacting constantly with the server Tlie server can always arbitrate in 
disputes. 

25 (2) Proxy-Mode: Some other entity is acting as proxy for the server. This would 

typically be the case when a small group of users wanted to play a " local" game. The proxy 
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will prevent iiinvai ranted creation, dcstruclidn. and akeraliiMi of objects in the local yanie, and 
will try to guarantee that no cheatinu done in the local i^anie (even invt^lving all participants) 
can allow cheatin;4 in the glohal uanie Note that in many circiinistanccs, one player in a group 
might be trusted enougii to be the proxy. 

S 

(3) Group-Mode A small group of players is interacting without even a proxy 
server. In this case, the group themselves must probably take on the proxy sei-ver's tasks, 
probably by delegating one of their machines to server as the proxy server. 

10 (4) Player-Mode In Player Mode, there is a single player playing the game alone 

I lis machine is eOectively the proxy seryer. 

In any of these modes, objects may be transferred aroinid between players, and may 
also (in some cases) be discarded or picked up It may make sense to have a user ID for a 
1 5 player called "nobody," and have this user 10 pcxssess things that have been discarded There 
may be one such user ID used for each dilVercnt game or "wc^rld" that's going on, i.e. each 
Proxy Sei'ver may have its own. 

Sei*\'er-Mo(le 

In Server-Mode, security concerns ahnost disappear Presenting users with signed 
20 versions of their ownership certificates is unimportant, as is verilying those signatures: instead, 
the server keeps track of everything. 4 his mode needs only tw-o [)rotocols-the one for 
preparing to leave this mode for some other mode, and the one for coming back to this mode 
from some other mode, i lere, we also discuss the format of object ownership documents and 
object transfer documents. 

25 1. Ownership Documents 

An ownership document is a signed docimient from the server, affirming liiat at some 
time, 4\ a given player was in possession of a given object, with a given set of attributes and 
conditions. 
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10 



20 



riuis, it is structured as 



Held nauic 



bits 



a, hashC'Transactiou Systcni-Ownership l)i)cunient" 160 



b Version 



c length of docunient 



d. Player ID 



e. Player Public Key 



r Object ID 



Object Data and Attributes 



h Attribute Transfer Condition 



Time at which this document was made 



j Time at which this document expires 



k. Signature on fields a j 



32 
32 
64 

1024-2048 
64 

variable 
variable *^ 
32 
32 

1024-2048 



*^ Variable-length fields always start with a 32-bit letigtli identifier All 
lengths arc given in bits, but all fields are continued out to the next full byte, if the length field 
is zero, then that's all the data in that field. 

** Object Data and Attributes may change after this docunient is issued in 
some cases, /.c, a gun with a limited nimiber of bullets. Implementations need to be flexible 
enough to allow this, wiiile doing some object-type specific tests to ensure that (for example) 
the magic lamp hasn't wound up with more wishes than it started vvitiv 

A variety of dilfercnt implementations and structures for ownership documents used in 
connectit)n with ertibodiments of a Transactor system will be apparent to those skilled in the 
art based on the present disclosure. 
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2 ILxit Protocol 

The player wants to be able to [)tay at some other mode I herefore, he requests an 
"exit visa" from the central server, to allow him to take part in other games. This works as 
ibilovvs: 

5 a. The Player forms 

UO - hash( "Transactor System-L-xit Visa Request") 
VO version 

LO -- length oi'lhuil message, including signature. 

RO " a random number 0164 bits 
10 XO - II0,V0,L0,R0 

and sends to the Server 

MO XO,Sign^{SK _PKXO) 
b I he Server forms 

Ul - hashf "Transactor Systeni--Challenge for l:xit Visa Request") 
15 V 1 ~ version 

LI = length of Final message, including signature. 

Rl a random number of 64 bits 

XI - UI,VI,Ll,hash(MO),R] 

and sends to the Player 
20 Ml - Xl,Sign JSK^SK.Xl). 

c. The Player forms 
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U2 - hasliC'Tiansactt)! System— Kcspoiisc for I-xil Visa Rcc|iicst") 
V2 - version 

L2 - length ot whole linal message, including signature 
X2 - U2,V2J.2,hash(IVIl) 
S and sends to the Server 

M2 - X2,Sign {SK_P!(X2). 
d The Server forms 

U3 = hash ("Transactor System— Rxi I Visa Transmission" ) 
U3a ~ hashf" Transactor Svstem— [{xit Visa") 
10 V3 version 

L3 ^ length oT whole message, including signature, 
L3a length of whole HxitVisa, including signature. 

SO[ l ..n|, where SO[i | signed object ownership statement lor object i, and n 
- the number t^f objects 

1 5 owned by the user, 

TS = valid time span 

C P ^ certificate of P's public key 

R3 ^ a random number of 64 bits 

K3 - a random encryption key 
20 X3 - U3a,V3,L3a,hash(M2)JG,C_>'''I'S,SO[ l .n| 

HxitVisa - X3,Sign_{ SK_S}(X3) 

51 



BNSDOCID: -iWO _.984709tA1 .1 



SUBSTITUTE SHEET (RULE 26) 



wo 98/47091 I>CT/L(S98/07I76 

and sends lo the l^iayer 

M3 - U3A'^I^3J'KI: 11>K PKi<^^)^I^..M<-^!n'^>^»^Visa) 

V [-ntranec Protocol 
a. I he Player forms 
5 UO hash( "Transactor System--rinlrance Visa Rec|ucst") 

VO version 

LX) letigih of whole final message, includini; sii^natme 
RO =" a random number or64 bits 
XO - U().VO,LO,RO 
10 and sends lo the Server 

MO - XO,Sign |SK_P|(XO) 
I) The Server forms 

Ui ^ hashC'Transactor Systeni--I'nlrance Visa Cliallenge") 
V t ^ version 

15 LI = length of whole final message, including signature 

Rl a random number of 64 bits 

XI = UKVI,LI,hash(MOKRI 

and sends to the Player 

Ml - XI,Sign JSK_S((XI) 
20 c. The Player forms 



BNSDOCID: '.WO_ ,9847091A1 J 



SUBSTITUTE SHEET (RULE 26) 



VV<) 98/47()9I rCI7l)S.)8/07176 

1.12 " liasliC* I raiisacU)! Syslcni--L:iitraiice Visa Tiansinissiiur') 
U2a hasli( "Transactor Systeni"I*iUrancc Visa") 
V2 - VLM sion 

L2 =" length of whole siuned and encrypted message 

5 L2a length of EntranceVisa 

ProxyLxitVisa - the exit visa from the proxy server or the central server 

K2 -- a random encr\'piion key 

X2 - U2a,V2J.2aJiash(M 1 ),IVoxvl.-\ilVisa 

luUranceVisa ■= X2,Sign(X2) 

10 and sends to the Server 

M2 - U2,V2,L2J>Kn j PK S |(K2),n | K2 [(Entrance Visa) 

d After this message iias been decrypted and verified, tlie Server checks to sec if any 
of the changes are in contradiction with other thnigs (restrictit)ns on objects, existing owner- 
ship records, etc ) If nt)t, then the Server forms 

15 {)^ ^ hash( " Transactor System-Entrance Visa Acknowledgment") 

V3 version 

L3 - hnal length of M3 

MESSAGE ^ any message that needs to be sent to the Player f I'his could be 
encrypted i f necessary. ) 

20 X3 - U3,V3,L3,hash(M2),MESSAGE 

and sends back tt) the Player 
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M:^ - X3,SiL;n >SK S|(X.>) 

Proxy-Motic 

Proxy-Mt)dc is also relatively easy to secure The Proxy takes on the tasks of tiie 
Server—so long as these are done honestly, the whole system should work almost exactly like 
5 Server-Mode. However, ifthc Proxy is dishonest, then its dishonesty (at least in changing 
around object ownerships) should be easily detected 

I . Transfer Documents in Proxy-Mode 

In this mode, transfers without revealing objects' histories directly to the receiving 
users are allowed. This prevents oin- system revealing things which players might want to 
10 keep secret ( l or example, if Alice really hates Bob, she may not want to trade with Carol, if 
she knows that Carol is also trading with Rob. In the real world, objects usually don't know 
their previous t>wncrs. ) 

In Proxy-Mode, the Proxy Server issues transfer documents These arc ol'the 
following general tbrmat: 

1 3 a. hashC'Transactor System-'f ransfer Document") 

b. Version 

c Length of whole transfer document, including signature 

d. FromlMayerlD - ID of the player from whom object was transferred 

e ToPlayerlD - ID of the player to whom the object was transferred. 

20 f Proxy SerA'er ID and Certificate, 

g. Object ID 

h Object Data and Attributes 

i. Conditions on Transfers 
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j. i'imc ol Trcinsrcr 

k Tinic this Docuniciit l-\pircs 

I. Audil'l rail, as discussed below 

111, Siii;n_ !SK J PrdxyServer | | (Tieids a I) 

S 2 Audit Trails 

Audit trails to ensure that the Server can uiUangie fraud or errors in object transfers 
can be implemented in this mode. An audit trail contains the previous transfer document, 
encrypted under the server's public key I his document will get larger for each transfer, which 
will leak information about this object's past This limited information leakage does not 
10 present a problem, however, in many embodiments. 

1 he structure of an AuditTrail is: 

a. UO ^ iiashC Transactor System-- AuditTrail (Proxy)") 

b. version 

c. length of whole Audit Trail. 

LS d. PKE I PK S [(KG), where KG is a random encryption key 

e. H ! KG [(Previous I ransfer Document ) 

Note that if there is no previous transfer document, we simply set the length field here 
to 224, which makes it clear tiiat there's nothing that follows this field. 

3. Entrance iVotocol 
20 Entrance into the game being run by the proxy server occurs as follows: 

a. The Player forms 

UO ^ hash(" Transactor System-Entry Retjuest (Proxy)") 
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VO version 

1,0 Iciiglh of whole linai iDcssai^c, incliidini^ signature 
RO ^ a random number oi'(vl bits 

C_P certificate or[)layer's public key, from Exit Visa. ' 
5 XO - IJO,VO,LO,RO,C_P 

and sends to tlie iVoxy Server 
M0= Xa,Sign [SKJ^KXO) 

b. f ile l^roxv Server verifies the certificate and signature, and then forms 

Ul hashC'Transactor System— luitry Cliallenge (Proxy)") 
10 V 1 ~ version 

f. 1 "^^ length of whole Una! message, including signature 
Rl a random number ol'64 bits 

C O ^= certificate of the proxy server's public key, given by the centrarservcr 
XI - UI,Vl,LlJiash(MO),Rl,C._S 
1 5 and sends to the Player 

Ml = XKSign jSK QIfXl). 

c. The Player forms 

U2 ^ hash(" Transactor System— Entry Response Envelope (Proxy)") 
U2a = hash("Transactor System-Entry Response (Proxy)") 
20 V2 " version 
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L2 iiiuil Icnulh orM2 

L2a - Itnal leiiiith o[ Y2 

K2 ~ a random cncr\'p(ioii key 

K2 ^ a raiKloin luinibcr of 64 bits 
3 lixilVisa - the L'ixit Visa u,\vcn by the central server earlier 

X2 ■■ lJ2a,V2,L2a,hash{MI)Jl2,E\itVisa 

V2- X2,Sign | SK l>|(X2) 

and sends to the I^oxy Server 

M2 U2,V2,L2,PKi:. |PK_Q((K2),l: l'v2|(Y2). 
10 d The iVoxy Server Ibrms 

l.f.l hasii{ " Transactor System— Hntry Acceptance Envelope (I^oxy)") 

U3a hashC'Transactor System— Entry Acceptance (Proxy)") 

V3 - version 

U - final length of"M3 
15 L3a - linal length of Y3 

PlayerData - Data needed by the player to jom the game 

X3 - U3a,V-^,E-^a,hash(M2).PlayerL)ala 

Y3 - X3,Sign ISK PKX3) 

K3 a random encr^'piion key 
20 and sends to I he Player 
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M} " ll.VV:vL.VlM<l: |I»K PKK.MJ'v !K3[(V3). 

c, I'hc Pr oxy makes sonic kind of note to tell tlie central Server that the Phiver joined 
the game at this time When this is delivered, the central Server is able to detect various kinds 
of cheating To form this note (whose method of delivery is still unspecilied), the l*roxv forms 

s 

114 ^ hashC'Transactor System-l-ntiy Acceptance Note (Proxy)") 
V4 ^ version 
L'1 fmal length ofN'H 
I DP - ID oi" player 
10 r - timestump 

X4 - lj4,V4,L4,ID_P;T\hash(ExitVisa) 
and sends to the central Server 
M4 - X4,Sign_{SK_r)KX4). 

4 L'xit Protocol 

1 IZxit from the game being run bv the |)roxy server is relatively simple The transfers 

have all been sent, and the Proxy Server knows enough to form the messages needed to 
convince the Server that things are on the level. 

a Tlie Player forms 

UO ^= hashC'Transactor System— Lixit Visa Request (Proxy)") 

20 RO a random number of 64 bits 

VO ^ version 

LO - tlnal length of MO 
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XO " lfOA''0,LO,R() 
and seiids to the Pa)xy 
MO - XO,Sign_ |SK Pi(X()) 
I) Tiic Proxy forms 

111 - hashC'Traiisaclor Systeiii-I-xit Visa ( luillcngc (Proxy)") 

Kl a random number of 64 bits 

VI ^ version 

LI = final length of Ml 

XI - UI,VI,LMuish(MO),RI 

and sends to the Player 

Ml XLSign ISK QKXl) 

c. The Player forms 

IJ2 - hashC'Transactor System-f-xil Visa Response (Proxy)") 

V2 ~ version 

L2 - final length of M2 

X2 = U2,V2,L2jiash(Ml) 

and sends to the Proxy 

M2- X2,Sign_iSK_PK.X2). 

d. The Proxy forms 

U3 hashC'Transactor System-Exit Visa Response Envelope (IVoxy)") 
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ll.ui • luisiiC'Tiaiisacior Svstcin--L:xil Visa Response (Proxy)") 

V> version 

1..-'^ linal length orM3 

L3a ^ lliuil length of Y3 

r()| I n] transfer ciiains for all n ohjects the Player lias transferred. 

l'!\itVisa the BxilVisa issued to this Player by the central Server 

\;> - U:>a,V.l,L3aJiash(M2)XxitVisa,TO[!..nl 

Pi()xvi:xitVisa - X3,SignJSK Q;(X3) 

K3 - a random encryption key 

K4 a random encryption key 

and sends to the Player 

M3 U3,V3X3J^KF. {PK P|(K3)J::_{K3!(ProxyiZxitVisa), 

and sends to the central Server (possibly through a slower channel) 

M3a - inA''3JJJ'K[.{ IPK S[(K4)j: {K4}(Pro\yL'xilVisa) 

In step d, it is not a security problem irK3 - K4-the protocol is specified this way to 
allow ini[)lemcniations where it would be harder to use the same key for both messages. Also 
note that irK3 K4, it is very important that proper padding schemes be used in some public 
key schemes, such as RSA, to avoid various kinds of problems. 

5 Transfer of Object 

Transference of an object during play is simple: In the following, Alice is the player 
that starts out owning the object, and Bob is the player that ends up owning tlie object. 
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a. Alice fornis 

l.lf) hasii( "Transactor Systcni--Transier Request F-iivelope (Proxy)") 
IJOa = fiashC Transactor Systeni-- Transfer Kec|uest ( Proxy)") 
VO ' version 

5 1,0 =-- final length of MO including cnci^ption 

L.Oa ■ final length of YO 
ID B - Bob's ID 
RO - a random number of 64 bits 

ObjeclDocument the current object ownership document 
10 XO U0a,V(),L0a,R0JD_B,Ob}ectDocument 

YO " X0,Sign !SI< A[(X0) 
KO - a random encryption key 
and sends to the Proxy 

MO - UO,VO,LO,PKf£ iPK_Q}(KOKLi {KO}fY()) 
15 b. The Proxy decrypts and verifies the message. If all is well, it forms 

Ul ^ hash("1'ransactor System-Transfer Challenge 1 Envelope (Proxy)") 

Ula hashC'Transactor System- Transfer Challenge 1 (Proxy)") 

VI ^ version 

LI ^ final length of Ml 
20 Lla - fmal length of YI 
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Rl - a random iiiiinbcr of 64 hits 

Desciiplion ^ A dcscripiion of llic requested transfer, ineiuding descrii)tions of 
the object and any 

changes or costs from the Proxy Server, 
S Xi - UlaA'MJaJll, Description 

Yl - XKSign ISK QKXi) 
K 1 a random encryption key 
anti sends to Boh 

M I - I J 1 , V 1 .L I ,PKE .! PK B ! f K 1 ),r*: IK 1 \(Y I ). 

]() c. Bob decrypts and verifies (lie message. If he doesn't want to allow the transfer, he 

can send any message that isn't the expected response, and the transfer will fail If he does 
want to allow (he transter, then he forms 

U2 = hashC' Transactor System- Transfer Response I (Proxy)") 

V2 versioti 
15 ' L2- final length of M2 

R2 a random number oi'64 bits 

X2- U2,V2,L2,hash(Ml)Jl2 

and sends to the Proxy Server 

M2 - X2,Sign^iSKJ31(X2) 
20 d. fhe Proxy verifies this message. If all is well, then it next forms 

U3 =^ hash( "Transactor System-Transfer Challenge 2 (Proxy)") 
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[J filial Icimlli orivi:> 
\/} := version 

R3 ^ a random luiinbcr ofO'l biis 

X3 - U3,V:v[.3Juish(M0),R3 
5 and sends to Alice 

M3 - X3,Sign .|SK Q}(X3). 
e, Alice verifies this message. If all is well, she then forms 

lj4 liash( 'Transactor System- Transfer Response 2 (Proxy)") 

L4 = final length of IV14 
1 0 V4 '■= version 

X4 - U4,V4,L4,hash(M3) 

and sends to the i'roxy 

M4- X4,Sign JSK_A;(X4) 
f fhe Proxy verifies this message. If all is well, it then forms 
1 5 U5 hashf/Transactor System-Transfer Notification Envelope (Proxy)'*) 

U5a - hash('*Tiansacror System-'fransfer Notification (Proxy)") 

V5 - version 

L5 ^ final length of 

L5a final length of Y5 
20 TransferDocument a transfer docLiment, as described above. 
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X5 U5a,V'5,l..5a,liash(M2)/l'ransicrDocLiinijiu 
Y5 - X.^Siyn |SK_Q|(X5) 
K5 ^ a random cncryi)ti()n key 
and sends to Boh 

5 MS - l)5A^'^J-^SJJKl:_{PK_n;lK5),lr:_{K5|(V5) 

Croup-iVIode 

In C]ioii[)-iVfodc, a yroup oi'two or more players i^et together without a tnutually 
trusted server. I "his makes the protocols much harder to make resistant to various kinds of 
cheating The preferred solution is [o designate one of the players' machines as the Proxy 
10 SerA'er, and im()letnent the proxy mode security system described above 

Player-iVIodc 

In Phiyer-Mode, the Player controls his own computer There are many opportunities 
for cheating here, but none of them should involve transfer of objects between this Player and 
others. 

I S A wide variety of error message formats in all these i)rotocols will be apparent to those 

skilled in the art based on the [)resent disclosure A simple set of exemplary error codes are 
set forth below. 

l:rror Code Meaning 

OxOOOOOOOO No Error Generally Not Used 

20 0x00000001 Ownership document version invalid 

0x00000002 Ownership document structure invalid 

0x00000003 Ownership document signature invalid 
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l)\000()()()(M Ownership docuinenl lime range invalid 

()\()00(K)0()5 Ownership document length field invalid 

0x00000006 Ownership document -- miscellaneous error 

0x00000007 Message length invalid 

5 OxOOOOOOOS Message version invalid 

0x00000000 Message signature iiivahd 

OxOOOOOOOa Message hash chain invalid 

f)xOOOOOOOh Message header invalid 

OxOOOOOOOc Message not decrypted successfully 

10 OxOOOOOOOd Message format invahd 

OxOOOOOOOe Message out of sec|uerice 

OxOOOOOOOf Message -- miscellaneous error 

0x0000001 I Wrapped message length invalid 

0x00000012 VVrapj)ed message version invalid 

I 5 0x000000 1 3 Wrapped message signature invalid 

0x00000014 Wrapped message hash chain invalid 

0x000000 1 S Wrapped message header invalid 

0x00000016 Wrapped message not dccr\^pted successfully 

0x0000001 7 Wrapped message format invalid 

20 0x000000 1 8 Wrapped message out of sequence 
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Ox()()0()0()lv> VVrap[)L'd incssauc - -niisccllancous error 

OxOOOOOOla Certificate siunaturc invalid 

OxOOOOOOlb ( ertificate expired 

OxOOOOOOlc Certdicate format invalid 

UxOOOOOO 1 d Certificate - -niiscellaneous error 

OxOOOOOOle Transfer Document version invalid 

0x000000 1 f 'f ransfer Document length invalid 

0x00000020 Transfer Document ID invalid 

0x00000021 1"ianster Docmnent iVoxy Server ID invalid 

0x00000022 Transfer Document Obieet ID invalid 

{)x0OOOOO23 I ransier Document Object Data/ Attributes invalid 

0x00000024 fransfer [document Conditions on fransfcrs invalid 

0x00000025 fransfer Document Time of Transfer Invalid 

0x00000026 fransler Dt>cument Expired 

0x00000027 fransfer Document Signature Invalid 

0x00000028 Transfer Document — Miscellaneous Error 

0x00000029 Player ID invalid 

0x0000002a Object ID invalid 

Ox0000002b Miscellaneous error 

0x0000002c Internal error 
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The present invention is dctincd by the claims, i he alx>\'e description of preferred 
enibodinieius illustrates certain representative inipleinenlations and applications ot tlie present 
invention, and does not limit the scope of the invention ilselt. 
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CLAIMS 

1 I . A digital tihjcct owricishij) system, comprising: 

2 a piLii ality ol usci terminals, each of said user terminals being accessible by at least one 

3 individual user; 

4 at least one central computer system, said central coihpiUer system being capable of 

5 communicating with each of said user terminals; and 

6 a plurality of digital objects, each ol'saici digital objects having a unique object 

7 idcntificatitui code, eacii of saiti digital objects being assigned to an owner, said digital objects 

8 being persistent such that each t)f said digital objects is accessible by a particular user both 

9 when said user's terminal is in communicatioti with said central computer system and also 
10 when said terminal is not in communication with said central computer system, said object 
I I having utility in connection with comnumicalit)n over a network, said utility ret|uiring the 
12 presence of the object identification code and proof of ownership 

1 2 ihe digital object ownership system of Claim I, wherein said central computer 

2 system comprises a central server and an t>wnership database identifying an owner associated 

3 with each of the digital objects. 

1 3. The digital object ownership system of Claim I, wherein said central computer 

2 system issues an ownership certificate to the owjier of an object. 

1 4 The digital object ownership system of Claim 3, wherein the ownership 

2 certificate comprises a cryptographically signed data structure, said data structure comprising 

3 an object identification code, a user code associated with the owner of the object, a key 

4 associated with the central computer system, an ownership certificate issuance date, and an 

5 object expiration date 

1 The digital object ownership system of Claim 3, wherein said central computer 

2 system maintains at least one certificate revocation list identifying ownership certificates that 

3 are no longer valid. 
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1 (> The diLiilal object ownership system of Claim wherein objects are transi'er- 

2 able among owners, 

1 7 The digital object ownership system olTlaim (\ wherein objects are transfer- 

2 able online. 

1 8 The digital object (uvnership system of Claim 6, wherein objects are transfer- 

2 able oflline 

1 0 The digital object ownership system of Claim 8, wherein a transfer certificate is 

2 created when an object is transferred oHline, said transfer ceitificate comprising the ownership 

3 certificate of the object, a code identifying the new owner of the object, and the date of the 

4 transfer, 

1 10 fhe digital object ownership system of Claim 9, wherein the transfer certifi- 

2 cates are ciyptographically signed by the owner designated in the ownership certificate 

1 11. The digital object ownership system of Claim 2, wherein said central computer 

2 system further comprises a plurality of peripheral servers, each game server being capable of 

3 communicating with a plurality of said user terminals and with said central server 

1 12, The digital object ownership system of Claim 1, wherein each object comprises 

2 at least one immutable attribute and a plurality of repiicable attributes; 

1 13 The digital object ownership system of Claim 1, wherein each object is assigned 

2 a duration. 

1 14 The digital object ownership system of Claim 6, wherein objects are transfer- 

2 able in exchange for payment. 

1 15. The digital object ownership system of Claim 14, wherein said payment 

2 comprises negotiable currency 

1 16 The digital object ownership system of Claim 1, wherein said users are 

2 interactive game players and said digital objects are game objects. 
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1 7 A property object in :i conipuLcr-rt'adablc incdiiini. the object beitig associated 
vvitli an owner, tlie properly object coniprisinLi;: 



3 at least one imnuitable altribute; 

4 a plurality ol replicable attributes, at least one of said replicable attributes having utility 

5 vvlien presented in connection with a coniniunication over a network, said utility rec|uiring the 

6 jiresence oftlie inimulable attribute in the object and proof ofownership is presented by the 

7 owner. 

1 1 8. The pi opcrty object of Claim 1 7, wherein each object has as associated 

2 ownership record identifying an owner of the object, 

1 10. The property object of Claim 18, wherein the ownership l ecord is embedded iti 

2 the object 

1 20. The pi operty object of Claim 1 8, whei ein the ownership record is separate 

2 from the object 

1 21 . The property object of Claim 1 7, wherein the immutable attribute comprises an 

2 object idetitification code 



1 22. The property object of Claim 2 I , wherein the object identification code 

2 comprises a serial number. 

1 23 The property object of Claim 2 1 , wherein the object identification code 

2 comprises an object type code. 

1 24. The property object of Claim 2 1 , wherein the object identification code 

2 comprises a hash of data representing replicable attributes. 

1 25. The property object of Claim 1 7 wherein the ownership record comprises an 

2 ownership certificate. 

1 26. The property object of Claim 25, wherein the immutable attribute comprises an 

2 object identification code, a user code is associated with the owner of the object, and the 
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3 ownership ccrtitlaitc comprises a cryptoL;raphic siunaturc l)iiHlitiu llie ohjccl identification 

4 code and a code associated with tlie owner 

1 27. The property object ofClaim 25. wherein the ownership record identities a 

2 duration oi' the otiject. 

1 28 The property object of Claim 25, wherein the ownership certificate comprises a 

2 cryptographically signed data structure, said data structure comprising an object identification 

3 code, a user code associated with the owner of the object, a key associated with an issuer of 

4 the certificate, an ownership certificate issuance date, and an object expiration date. 

1 29. The property object of Claim 17, wherein ownership of an object may be 

2 transferretl offline, and further wherein a transaction record for recording oil-line transfers of 

3 ownership of the object is associated with the object 

1 30 The property object of Claim 17, wherein the object is an object ibr use in an 

2 online game 

I 31. The property object of Claim 1 7, wlierein ownership of the object is persistent 

1 32 The property object of Claim 1 7, wherein ownership of the object is transfer- 

2 able. 

1 33 A digital object ownership server system for conducting interactions with a 

2 plurality of users over a computer network, said interactions involving objects owned by at 

3 least one of said game players, ownership of said objects being transferable among players, 

4 said digital object ownership system comprising: 

5 a user registrar, said user registrar issuing user identification codes to each of said 

6 game players; 

7 an object registrar, said object registrar issuing object identification codes associated 

8 with each of said objects; and 

0 a bookkeeper, said bookkeeper associating each object with an owner, and validating 

10 ownership of said objects prior to use. 
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1 34 I he digital object ownership server system of Claim wherein said server 

2 system comprises a game server system for conduction an interactive game. 

1 35 The uame server system of Claim 33, further comprising an ownership database 

2 system, said ownership database system storing codes associated with each object, codes 

3 associated with each game player, and identifying at least one game players as the owner of 

4 each object 

1 36. The digital object ownership server system of Claim 33, wherein said system 

2 issues an ownership certificate to the owner of an object. 

1 37. The digital object ownership server system of Claim 36. wiierein the ownership 

2 certificate comprises a cryptographicaily signed data structure, said data structure comprising 

3 an object identification code, a user code associated with the player that owns the object, a 

4 key associated with the game server system, an ownership certificate issuance date, and an 

5 object expiration dale. 

1 38 The digital object ownership server system of Claim 36, wherein said system 

2 maintains at least one certificate revocation list identifying ownership certificates that are no 

3 longer valid. 

1 39. The digital object tnvnership server system of Claim 36, wher ein objects are 

2 transferable among owners olTline. 

1 40. The digital object ownership server system of Claim 39, wherein a transfer 

2 certificate is created when an object is transferred ollline, said transfer certificate comprising 

3 the ownership certificate of the object, a code identifying the new owner of the object, and the 

4 date of the transfer. 

1 41 The digital object ownership server system of Claim 40, wherein the transfer 

2 certificates are cryptographicaily signed by the owner designated in the ownership certificate. 

1 42. The digital object ownership server system of Claim 33, wherein said system 

2 comprises a central server and a plurality of game servers, each game server being capable of 

3 communicating with a plurality of game players and with said central server. 
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1 43 . A digital object tivviietsliip client syslcni ibr concluctiiiLi iiUcractioiis over a 

2 computer network, said client system comprising;: 

at least one user identilication system for encodinu signals transmitted over the 

4 computer network to identii'y a [iredetermined user as originating said signals: 

5 an object manager, said object manager maintaining records of digital objects owned 

6 by said user; and 

7 an object trader, said object trader enabling said user to transfer ownersliip of a digital 

8 object; 

9 a wrapper for wrapping a digital object with predetermined information associated 
10 with said user; and 

i 1 an unwrapper for unwrapping a wrapped digital object to separate the digital object 

12 and the predetermined information. 
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STVV I. ConsuMici f!^5) lous 
ontd Internet 



1^ The 
( Internet 
^ 60 



S I HP 2. CoiisiinKT logs ontd I ransactor-eniiblecl 
service provider Or directly ontct a Transactor |()^ 
Server. 



S I BP 3. Consumer 
decides to register as 
I ransactor user. 




S'lliP 'I. Consumer fdls 
out registration I'orni 
including Charge Account 
and Bank Account inlo. 

108 



STtP 5. Registration is 
submitted to i ransactor 
Server from site. | |() 



STtP 6. Transactor Server 
creates new account and 
issues [>rivate data: User key, 
password, etc. to Consumer. 

1 12 



S rr.P 8. Consumer is already a 
Transactor user. 



118 



STEP 7, Consumer receives and 
stores keys and data. 
Downloads or receives client 
sofrtwarc in mail. jj^i 



s rcp 1 


I. Consumer leaves site. 




128 



STEP *^ Consumer logs into the 
client-side I ransactor Object 
Manauer ( TOM) as a valid user. 



116 



STEP 10. Consinner decides t{> 
make a purchase. See FICi. 4 
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STEP I I . Consumer decides to 
check his Fransnctor account. 
See FIG. 5 122 



STEP 12. Consumer decides to 
post an object that he created 
tor sale. See FIG. 6 124 



FIG. 3 
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S I EP 13. Consumer decides to 
post a previously acquired 
object tor resale. See FIG. 7 

^^26 
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S'l'l-^!' 1. Consumer (35) decides lo make 
;i purchase. 



S IT.P 2. Consumer's TOM sends 
intent to purchiise <and appropriate 
IDs) to vendor's web site. 



204 



STEP Vendor's Transactor Broker 
Module creates Transaction Kecord 
tluU incorporates necessary vendor 
IDs, product info and vendor signature 
witli Consumer's info. 

206 



S TEP 1. Vendor sends Transaction 
Record to Consumer's TOM for 
signature. 



208 



STEP 5. Consumer's TOM confirms 
vendor's siunaiure and I ransaciion 



Kecord contents. 



210 



S I EP 6. Consumer's TOM signs tlie 
record and forwards it to the 
Transactor Server. 



S l EP 7. Consumer's TOM also 
notifies vendor's server that 
transaction lias heen signed and record 
lias been forwarded to the I ransactor 
Server. 2 1 4 



STEP S. Transactor Server validates 
Transaction kecord and contents, 
then issues OK or rejcctioii. 

216 



S I'EP 9b. Transactor Server changes 
object's ownership in database. 

It also determities all splits and fees 
for ail accounts involved - buyer, 
reseller, maker, service, etc. 

Transactions for each account are 
logged and new account balances arc 
computed. 



220 







STEP 10. Transactor Server sends 
purcliase OK to vendor's server. 

222 







STEP 1 I . Vendor's server receives 
purcliase OK, and repackages the 
existinii unit with Consumer's ID. 
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SI EP 12. Vendor's server sends object 
h} Consumer or sends notification of 
where t(^ download the object via (• TP. 
Sale is logged as complete. 



STEP 13. Ccmsumer's TOM server 
receives notice of tlie sale and 
downloads the object. A Transactor 
Server will verify the ownership of the 
object whenever it is used online. 

228 



If validation is OK 



Sl'EP 9a. The operaiitMi is not 
performed and the user is notified ot 
the failure. ^ , 



8 



If validation is not OK 

FIG. 4 

SUBSTITUTE SHEET (RULE 26) 



BNSDOCtD; tWO.,_ ye470ytAt .1 :• 



wo 98/47091 



rCI7lJS9H/07176 



5/9 



STKI* I . Consuiiicr (35 ) due ides to 
check his TVansacior iiccount. 



302 



STEP 2. Consumer s 1 OM sends 
intent to "purchase" account info (and 
appa)priaic IDs) to I ransactor Server 
directly or via 1 ransactor enabled web 
site or Broker server. I lie TOM may 
operate independently or through other 
rransactor-enabled client software. 



304 







STFI* 3. i ransactor Server sends 
validation challenge It) C^onsumer's 
TOM. ^ 306 







STRP t. Consumer's TOM responds to 
validatioti challenge. 



STEP 5. f ransactor Server receives 
response. -.^^ 



It validation is OK 



STFJ^ 6a. I he operation is not 
performed and the user is notified of 
the failure. 



11 validation is not OK 



STLi* 6b. I ransaclor Server allows 
Java applets (or other client so It ware) 
to "download" Consumer s account 
info (rtot persistent). 

314 



STKP 7. Consumer's TOM 
downloads, decrypts and displays 
account info using applets (or other 
client software) imbedded in web 
page (part of Liroker Module). 



STI-P 8. Consumer reviews account 
info (and perhaps other 
communications from Transactor 
Server). Consunicr logs off or 
proceeds to other Transactor activity. 

318 
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STEP 1. Registered Tain 
decides lo post an object 
for sale. 


sactor User (33) 
that he created 

402 






STLP 2. User logs into tl 
I ransiictor Object Manai. 
"package" liis object. 


c client-side 
,er(rOM)to 

404 






STEP 3. The 1 CM enters User ID 
(A I A 1 A 1 ) into the object package fields. 
The User inputs data regarding price, 
revenue model, number available, etc. 4()(^ 






STEP 4. The User logs o 
Server directly or a 1 ran* 
service provider, and is v 
Transactor Server. 


nto a Transactor 

;acit>r-enabled 

ahdaled bv a 

' 408 





S IT- 1* 'M). The Transactor Server creates 
a new unique unit 10 and assigns 
ownership of that unit to the huyer in its 
internal ownership databases. £j2() 






STEP 10 I he '! ransactor Server then 
packages the unit 11!) with ownership 
irilorniation and the digital product 
itself, encrypts portions of the resulting 
data, then sends the result to ihe user or 
in tonus the user where the packaged 
object may be downloaded. ^22 






STEP t 1 . The Tratisactor Server will 
also update all relevant accounts, 
compute and distribute splits, etc. 474 



STEP 5. The User uploads the packaged 
object and fields with instructions for the 
fransactor Server to create a new product. 

410 



STEI* 6. ITe i ransactor Server veriiles 
that it received the data correctly, then 
proceeds to create a product, giving it a 
unicjue product IIXBIBIBI). 



STEP 7. The fransactor Server sends the 
unique product II ), and other jiroduct- 
relaied information, back to the user. 



414 



S'lTlP 8. When copies of the product are 
sold, the 'fransactor Server will verify 
buyer's (37) 1 ran.sactor User status and 
the existence of available unsold units tor 
the buvL-r-designated product ID. 416 



If validation of LIser 11 > 
and prdduet ID is not OK 



If v;)lidalioi) nf User II") ;nul product 
il.) is UK 



STEP 9a. I he operation is not performed and tlie 
user is notified of the tailurc. I here i.s not sale. 
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STEI' 1 . Consumer decides to post a 
previously acquired object for resale. 

502 



STEP 2. Using the TOM, Consumer 
indicates asking price tor object and 
sends posting (and appropriate IDs 
including TOM signature) to Transacior 
Server. 

504 



> 




STFP 3. Transactor Server sends 
validation challenge to Consumer's 
TOM. ^ 506 


> 




STEP 4. Consumer's TOM responds to 
validation challenge. 

508 






STEP 5. Transactor 
response. 


Server receives 

510 



If validation is not OK 



II validation is OK 



STEP Ob. Transactor Server includes 
object posting in log oT objects 
currently Ibr sale "classifieds/' 

The object, or a pointer to the original 
object, is stored at a Broker Server for 
resale. 

514 



STEP 7. Anoilicr valid Transactor user. 
Consumer (36), logs onto a Transactor 
enabled web site and activates licr TOM 
to searcli Ibr an object lo purchase. 

516 



STEI* 8. Consumer 36 searches the 
Transactor ' classifieds" by object name, 
universe, price, etc. to find the desired 
object. 



S TEP 9. Consumer (36) locates the 
object posted by Cctnsumer (35) and 
decides to make a purchase. 
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STEI* 6a. I he operation is not 
performed and the user is notified of 
the failure. 



512 



S TEP 10. Consumer s (36) TOM 
.sends intent to purcliase (and 
appropriate IDs) to Btoker Server via 
Transactor-enabled web site. 

5^2 



STEP I I. Purchase process continues 
as ifi riCi. 4. with Broker Server 
acting as vendor. 

524 
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Unit ID 

Assigned to unil during Objccl creation. 
Incorporated in LL-DO during initial Object 
Purchase. 

602 



Owner ID 

• Assigned to user during User Registration. 
Incorporated in LEDO durinu Object i^trchasc. 

6(14 



Unit ID 

602 



Owner ID 
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Piiyload 



60(> 



LEDO 

("Limited Edition'^ Digital Object) 
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Payload 

Data which defnies object (textures, data pointers. 
A I. object attributes, etc.) 
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www tfansaclor.com 



736 
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Packaged Digital 





New Unit of 
Digital Object 



Product ID(DIOIDI) 770 



Usci (37) receives 
pack;med object with his 
Owner ID(CICICI) 
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